corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Question: unittest use of assert (peter??9
Date Fri, 26 Dec 2014 12:27:03 GMT
On Friday, December 26, 2014, Peter Kelly <> wrote:

> > On 26 Dec 2014, at 4:32 am, jan i < <javascript:;>>
> wrote:
> >
> > Hi.
> >
> > This is probably a question for Peter.
> >
> > I am currently writing unit tests using the new harness from Peter (which
> > is really nice). I did extent -plain a little bit.
> >
> > However all test functions are "void foo()", so if a test fails the
> > functions does an assert. This means the test run will stop at the first
> > error.
> >
> > Would it not be better to have "bool fool()", so a test run would run all
> > tests, meaning a tester might see multiple errors in one run.
> There’s two different assertion functions:
> assert - provided by the C library. This aborts the program on execution
> utassert - provided by DocFormats itself (defined in the unittest
> directory). This just causes a test to fail, without aborting execution of
> the program

I missed the difference thanks for the explanation.

> Assert is used in a number of places throughout the code in the main part
> of the library, for the usual sanity checks. I would suggest leaving these
> as-is, because an assertion failure in these places typically means that if
> it’s ignored then the program will crash or otherwise corrupt memory or
> something similarly bad anyway, just slightly later (the assertion catches
> the problem before it happens).
> utassert is intended for use in test cases only, where you want to ensure
> a particular condition is true. After calling it, execution of the test
> function will continue, but the result of the test would be failure.
> If we want to have a test harness that allows tests where the former
> assertion fails (causing the process to abort), we can do so by forking
> between each test (though this will not work on windows however, which
> lacks fork). This would also be helpful for problems which lead to NULL
> pointer de-references or memory corruption; each test would run in complete
> isolation from the other. This would be relatively easy to do and I can add
> this if you want (or you can do so yourself if you wish).
> I don’t personally feel a need for such a case, as far as my own
> development work goes. If I’m working away and introduce a bug that’s
> serious enough to cause a crash, I’ll generally fix it immediately before
> continuing. However if anyone else wants to have the isolation I’ve
> described above so that it can try later tests even if an earlier causes a
> crash (or assert() abortion - note this is distinct from utassert()) then
> this could be added to the test harness.

I agree with you an abort like NULL pointer should lead to a stop, and with
utassert test cases can fail for logical reasons without stopping other
test cases.

I will leave the test harness as it is, and I had no intention of changing
the assert in the production code
jan i

> —
> Dr Peter M. Kelly
> <javascript:;>
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

Sent from My iPad, sorry for any misspellings.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message