lib updates and test suite
rra at stanford.edu
Wed Jun 14 07:25:01 UTC 2000
I've just landed a bunch of stuff that I've been working on for a while.
I've added new implementations of concat.c, xmalloc.c, xwrite.c, and
strerror.c that I've been working on separately and which pass a
reasonably comprehensive test suite. There are no significant differences
between these and the ones we were using before beyond some additional
robustness, const cleanliness for xwritev, and modifications to both
xwrite and xwritev to handle EINTR error returns by restarting the
I've also committed the beginnings of a test suite that tests all of the
above implementations as well as error.c (which I committed a bit back
with the convdate rewrite).
Note that all of these files I also maintain separately as part of a
librutil (random utility) package that I'll probably release as its own
thing at some point down the road once it has some more stuff in it. Not
that this matters all that much to INN development; I'll be keeping them
in sync myself.
I'm going to add some information about the test suite to HACKING; adding
new tests is very straightforward and very flexible. Just write a program
that tests some part of INN, put it in a directory under tests named after
the part of INN it's testing (all the tests so far are in lib because
they're testing libinn routines), and have it output first a line
containing the test count and then for each test a line saying "ok ##" or
"not ok ##" where ## is the test number. Add any rules necessary to build
the test to tests/Makefile (note that for simplicity it doesn't recurse)
and add the name of the test to tests/TESTS. That's all there is to it.
Some naming conventions: All tests should end in .t (runtests expects
that). To distinguish more easily between e.g. lib/error.c (the
implementation) and tests/lib/error-t.c (the test suite), I've been adding
-t to the end of the test file names. So tests/lib/error-t.c is the
source that compiles into an executable tests/lib/error.t which is run by
putting a line in tests/TESTS of just "lib/error".
Let me know of any test suite failures with the current tests (I'll be
surprised if there are any right now, since I've tested it on a few
different platforms, but that's what the test suite is there for).
New tests, no matter how basic, are gratefully accepted if they're in the
above form and can be easily dropped in!
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers