Running events on assert failure

[9fcc]

I didn't found such in documentation, so decided to ask here. Can I add an event callback for assert in a test somehow? Something like this:

void test_something_cb(void *user_data)
{
// print full state of object some_data on assert.
}

START_TEST(test_something)
    struct some_data_t some_data;
    ck_add_fail_callback(test_something_cb, &some_data);
// ...
END_TEST

So callbacks can be added to linked list for running them on assert.
Without this feature tests are not so helpful, through I need much more info about object I'm testing. But I need it only if test fails.

[brarcher]

There is nothing like what you describe. However, one can have setup and teardown functions registered that run before and after tests.

Having a callback after a failure is detected may make things a little more complicated, as there is a chance that the callback itself may fail. Check's philosophy is to fail on the first failure observed. If one is interested in analyzing something on a failure, it may be better to restructure the test in the following way:

if(test_something == false)
{
   // report what is necessary to a log or stdout
   // invoke an assert and fail the test
}

If you believe that a callback may be valuable, can you provide a use case? What is the callback allowed to do or not allowed to do? After the callback is invoked is the test immediately stopped? If the test contains multi-threading is there a concern about not having exclusive access to a resource in the callback? Does the callback have a time limit to execute much how tests can timeout?

[9fcc]

I have an object that have many internal variables and input parameters and only two output variables. Than I check those two variables through time. There are about 6 asserts for those two variables. If any of them fails I need to find out the reason. So I wrote a function that prints to FILE* stream state of the object at the moment (valuable input parameters and internal variables). It is the best way to analyse situation to resolve problem. But I had to wrap floating asserts with manual checks and code of tests become less readable.

What I need is callback run in the assert right after it writes error message to the log file (or to stderr). Callback gets in its arguments FILE* stream to write to and writes all the debug information to that stream. After callback is finished assert stops the test. So logs would be with much more info about the error. And debugging becomes easier.

About timeout. Through callback needs only to write debug information (at least for my purposes), It would be very fast. But somebody could use it in his own way so may one pass custom timeout when registering callback. So one timeout to the test and another to callback. And default timeout for the callback with two registering function (without timeout and with it).

In case of multithreading user must protect the object by himself.

Additional callbacks could be useful if tests use many objects so state of all objects must be logged. In this case user could register callback right after he created the object.

To reduce amount of meaningless information callback could return 1 (true) or 0 (false). 1 would continue running other callbacks. 0 would stop the test. If all callbacks finished the test stops. It's like GTK+ project realized their callbacks.

[9fcc]

I thought about those callbacks a little more. Sometimes it's even better not to finish the test after assert. And it could be managed through a callback somehow. Sometimes I need to know what state the object would have after the assert. It helps find out problem source much faster. So another scenario would be such as assert runs callbacks and if some of them signalled (through return or through argument variable) the test continues but marks himself as failed writing debug data to the log. In such a way user can limit debug data written to the logs by himself.