Test case framework
Stathis Kamperis
ekamperi at gmail.com
Wed Oct 14 00:24:39 PDT 2009
Greetings to everyone!
During Google Summer of code 2009, I have written a lightweight test
case framework along with ~300 test cases. Recently, there were some
discussions in #dragonflybsd at EFNET on how to make it easy for
developers to contribute tests. The various options boil down to:
=== Commit the work in DragonFly's official source tree ===
Pros:
1. Developers that already have commit access can easily contribute tests.
2. There's no extra administrative cost.
Cons:
1. The test suite will look like a foreign body, because it isn't
integrated with our make infrastructure, contrary to what OpenBSD does
for example. This was and still is a conscious decision by my side,
since I'd like the tests to be able to run in other OSes as well. At
least those that refer to POSIX conformance. Currently we support a
plethora of them (*BSD, Linux, Open/Solaris). The test suite is a
piece of software by itself and the best way to stress it is to run it
in diverse environments.
2. Not all test cases are of equally high quality or importance -- I'm
honest here. And although one may reasonably stand up and start saying
that X Y Z test shouldn't get in, I wouldn't want to find myself in
such a tasteless discussion that can easily get subjective.
=== Setup a separate git repository replicating crater's commit access ===
Pros:
1. Developers that already have commit access can easily contribute tests.
2. No need to worry about *mk integration or which tests worth being
imported and whatnot.
Cons:
1. Someone needs to make it happen.
=== Send the tests to me and have the committed to my personal git
repository in leaf ===
Pros:
1. Zero administrative cost.
2. No need to worry about *mk integration or which tests worth being
imported and whatnot.
Cons:
1. No one will ever send me a test case.
Personally I'm leaning towards 2 or 1. Worst case scenario is 3, where
I keep working on my own until Real Life (TM) comes in, project fades
away and DragonFly is back to square one in terms of regression tests.
If we find a common ground of agreement, we can further discuss
technical issues. For instance, I'd like to rewrite the Makefiles to
make them use automatic variables, rather than the current cluttered
naive rules. Of course, provided that portability isn't compromised :)
The repository is available here:
http://gitweb.dragonflybsd.org/~beket/pcca-tests.git
In case anyone wants to give it a really quick shot:
$ git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git
$ cd pcca-tests
$ cat README | less # and make sure that the requirements of the
host OS are met
$ ./mktests.sh -sbr
Please let me know of any issue whatsoever you are faced with.
Best regards,
Stathis Kamperis
More information about the Kernel
mailing list