Michal Sojka [Sun, 20 Feb 2011 08:31:58 +0000 (09:31 +0100)]
wvtest: WVFAIL(cond) returns cond
Previously WVFAIL returned !cond. In my optinion it was confusing
because the statements
if (cond) print_error();
and
if (WVFAIL(cond)) print_error();
behaved differently. Now, they are functionally equivalent. In the
implementation we use C extensions typeof() and "statement expression"
to avoid duplication of side-effects caused by cond evaluation.
Michal Sojka [Tue, 8 Feb 2011 15:34:33 +0000 (16:34 +0100)]
wvtest: Show stringified expressions in WVPASSEQ/NE
Previously, WVPASSEQ(func(), 0) printed only "0 == 0 ok", whereas now,
it prints "func() == 0 == 0 ok". This is useful when the test fails so
that the real value is seen in the output e.g. "func() == 1 == 0 FAILED".
Michal Sojka [Thu, 13 Jan 2011 14:55:22 +0000 (15:55 +0100)]
Fix the C API to work under OS X
Using variable attributes to put data structures to a separate section
doesn't work as expected under OS X. The code doesn't even compile.
This patch removes the use of variable attributes and uses instead
function attribute "constructor". The functions marked by this attribute
are called before main() similarly as C++ constructors of global
variables.
These functions are used to register all the tests defined with
WVTEST_MAIN so that we can run all of them.
Michal Sojka [Tue, 14 Dec 2010 12:54:07 +0000 (13:54 +0100)]
Add wvtest for C
For some C programs it is not possible to use C++ implementation
because g++ compiler doesn't support "Designated Initializers"
extension of GCC. If this extension is used in C code, the code cannot
be compiled by g++ and therefore it cannot contain WVPASS and similar
macros implemented in C++.
This patch adds C support which is derived the C++ one. The code
relies on "variable attributes" (another GCC extension) to run all the
functions defined with WVTEST_MAIN(). C++ API uses constructors of
global variables to find all these functions but in C, something else
must be used.
Avery Pennarun [Sat, 26 Jun 2010 04:48:11 +0000 (00:48 -0400)]
Update wvtest.py to the new version that does os.chdir().
It was too annoying to test submodules, because if any of them opened a
file, they always had to mention the full path from the wvtest.py (which was
usually at the root of the whole project) to the data file (which was
usually in the t/ subdir of the submodule). So if you extracted a submodule
into its own project, all the paths would be wrong.
Now wvtest.py does os.chdir() into the t/ subdir being tested. If you don't
like that, you can always chdir into a parent directory.
wvtest.py: when exceptions are thrown, choose a better stack dump.
We already print the entire stack trace - the useful part - but we were
printing a kind of useless line number in the wvtest result line: the line
from which the exception was thrown. That's kind of weird, and doesn't help
indicate which test threw the exception. So let's pull out the current line
number from the running @wvtest function instead.
That's not perfect either, in case the function called a sub-function that
produced the exception, but it's somewhat more useful at least. You should
still read the full exception printout for maximum accuracy.
Avery Pennarun [Mon, 24 Nov 2008 22:28:39 +0000 (17:28 -0500)]
wvtestrunner: catch segfaults in the subprogram.
wvtestrunner would notice if the subprogram returned a non-zero exit code,
but not if it died on a signal. Thus, a unit test program dying on a
segfault was considered a success. Oops!
Avery Pennarun [Fri, 1 May 2009 01:02:00 +0000 (21:02 -0400)]
Replaced wvtesthelper/meter/colour scripts with an all-new wvtestrunner.pl.
This one is much smarter than previous versions: by default, it prints out
only the headers from "Testing blah blah:" lines and then prints just a "."
for each "! whatever ok" line. But, if a test does fail, it prints out
*all* the stdout/stderr that was produced by the test from the "Testing blah
blah" line all the way to the failing test.
It also auto-colours ok/FAILED lines, but only if stdout is a tty, so you
don't need to decide whether you want it coloured or not.
Finally, its output is actually compatible with itself: you can run a
top-level wvtestrunner and it'll further summarize the output of inner
wvtestrunners, because the complete output of a given testrunner is in a
single "Testing blah blah:" section. But if a failure occurs, you'll still
get the more detailed results.