added basic signal handling: this allows to see how far did we go in our...

[formiaczek]

... testing if, eg. the code under test hits a seg-fault.

First of all - thanks for a great test-framework! I find it very useful - both at work and when writing open-source c++ stuff.

I have seen my code hitting a segmentation fault few times, and had to add debug-code to my existing test cases to see what test was invoking the buggy code.

I created a wrapper, that was simply registering signal handler(s), and from this handler I simply printed out some info on what was the last test / check that has executed successfully, and this gives a huge hint on where to look for the fault cause. (please have a look if this is the right thing - perhaps it should be done differently?)

I thought this could be in catch, thus my pull request.

below is my example code, which reveals also a possible bug?. But this (and few other ideas) are probably for other pull requests I guess:)

Cheers,
Lukasz.

test code:

#define CATCH_CONFIG_MAIN
#include <catch.hpp>

#define REQUIRE_NOT_NULL( expr ) REQUIRE((expr) != (void*)NULL)
#define REQUIRE_NULL( expr ) REQUIRE((expr) == (void*)NULL)

#include <string.h>

TEST_CASE("my testcase", "should pass")
{
    char* ptr1 = NULL;
    char* ptr2 = ptr1++;

    REQUIRE_NOTHROW(ptr2++);

    // these two cause seg-fault (similarly for xxNOT_NULL with ptr2):
    // (it worked with previous versions of catch, so it might be a BUG of some sort?)
    REQUIRE(ptr1 == NULL);
    REQUIRE_NULL(ptr1);


    // this one is expected to fail, obviously..
    REQUIRE_NOTHROW(ptr2[32]  = 'd');
}

and this gives me following info, when executing:

./example_test

Segmentation violation

while executing test: "my testcase"

(last successful check was: "ptr2++"
in: example_test.cpp, line: 26)

[martinmoene]

[Added C++ ... around code]

[philsquared]

Thanks for this. I've not had a chance to look at this properly yet - but it's definitely on my list. Handling signals/ SEH exceptions (windows) has been on my todo list since the beginning (#3)

I just wanted to make sure you didn't think I was ignoring you.
More soon...

[formiaczek]

Hi, Thanks for reply. No worries - I've been quite busy recently too. Let me know if I could provide any help on the above.

In addition, I also attempted on adding a maximum time-out for the test-suite. This could handle test suites in which the code being exercised hangs for any reason (I did have such a test-case at least once). And instead of the build-system hanging on a build, or timing-out, it could simply be a test-case failure, build could continue and so could other, unrelated tests that would normally follow.

For this, Catch could perhaps have a default, (presumably alterable by a command-line option) value for the maximum time-out the Catch::Main() should take up to. In such option, however, it would be hard to tell what the right value should be (i.e. big enough for longest possible test-suites people out there have, but still reasonably small to capture hangs in 'overnight tests').

Alternative for that could be to have such a time-out as either command-line option or macro-defined, and people, who would wish to use it could then adjust the value for themselves. But this is probably a thread for another discussion / pull request - if I find more time I might try to create one and then will move this message across.

Thanks,
L.

[philsquared]

Sorry, I think this got closed automatically because I deleted the integration branch. It doesn't mean I'm not interested.
I'm not sure if the PR can be re-targeted?

[formiaczek]

What do you mean by re-targeting?