-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing C code that abort()s #31
Comments
When the test is executed in a child process, it should sort of work already because the parent process should see strange exit code. (Maybe it leads to a sub-optimal message because currently the parent process assumes that calling When in the same process, it's completely different story. I can't see any other potential way then the However right now I am somewhat reserved because I see it as a quite crazy thing a process can do and I have some doubts about it:
To conclude, feel free to go ahead and implement it, but be prepared that those questions will have to be answered in some reasonable way before anything like that gets merged. |
Oops. Sorry. Ignore the previous post. I missed the point you want to make your test succeed when it does |
I think my doubt (2) could be solved by installing/uninstalling the handler just for the time of the macro. But my doubts (1) and (3) still hold. Also, if we want a new macro like To be honest, I'm somewhat skeptical in that regard but feel free to argue or show a code proving I'm wrong ;-) |
Also see #18. Maybe some of the arguments used there apply here too. |
Thinking about this a little bit more, I now believe it is a bad idea. Let me react to some statements in the original post.
I disagree. In C++, exceptions are more or less normal error handling mechanism and, for example, part of various library APIs. I.e. it is important that for a given known and documented error condition (e.g. an invalid parameter passed to a function) some API signals the error to the caller in some expected way (here, some particular exception type) and that this can be tested. On the other hand, From this perspective, C++ exceptions are rather a cousin of some special return values like
I agree good test coverage is generally a nice thing to have. But it is not the goal of the testing per se. It's only some helper metrics. Value of that metrics has its limits. This question of I argue that in a correct program, if there are code paths leading to If you are able to write a test causing an assertion in the tested code, you should likely rather go and fix the code so it does not have a reason to raise the assertion in the first place (and hence change it to the program which cannot have 100% code coverage in principle as stated above). To conclude, the very fact that it asserts means the program has some problem. Providing a mechanism saying "hey, the test passes" in such case imho makes no real sense. |
Thanks a lot for this super neat test library!
One useful feature I feel is missing is the ability to test a function that is meant to
abort()
, typically due to some failingassert(...)
in the code. It can be viewed as the poor cousin ofTEST_EXCEPTION
for C. It's useful for testing that problematic conditions are properly detected andabort
ed. Moreover, such tests are useful for reaching 100% branch coverage, otherwise one branch of theassert
is never hit.This should be easily implementable by trapping
SIGABRT
andlongjmp
ing back in the test. It can be namedTEST_ABORT
,TEST_SIGNAL
(maybe for testing any signal) or something like that.Your thoughts? If you're interested I can give it a shot.
The text was updated successfully, but these errors were encountered: