Re: g_assert_handler for unit-tests

Stefan Kost <kost imn htwk-leipzig de> writes:

> hi hi,
> we extensivly use g_assert() as API precondition checks in our project. Further
> we have a bunch of unit tests based on check [1].
> When one writes unit tests this included trying to misuse the API (e.g. passing
> NULL pointers and the like). Now if there api entry that is checked is still
> buggy, the tessts e.g. crash and therewith the unit-testing framework considers
> this as a failed test. When the developer now fix the function by assing some
> g_asserts() the unit test still fails, as the programm now exits().
> Next I would like to outline a solution for the probelm. I don't have commit
> regith to gnome CVS, so if there is agreement I will also provide a patch for it.
> As a solution I suggest to introduce a g_assert_handler(). The default
> g_assert_handler will call exit() and will be installed by  glib on init().
> An application could then use a new API entry g_set_assert_handler() to install
> a new handler and to store the old handle so that later it can be restored.
> The assert_handler gets
> a) the log-message as the only argument
> -or-
> b) file,line,func,expr,... as separate args.
> In the unit test we could install our own assert-handler. That even allows to
> verify wheter the tested module has handled the wrong arg (by checking func).
> What do you thing about it? Is it all nonsesnse and is there an easier way? How
> do you handle such things?

Just don't use g_assert() for precondition checks.

Use g_return_[val_]_if_fail() instead and control the fatality of
the warnings it issues with g_log_set_fatal_mask() or

Also look at gmessages.h to see how to install log handlers for
messages of any severity.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]