This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: growth agendas and OO
> Given that Xconq is rather large, a good test suite would be most
> useful. That way the developer can reasonably quickly check if the
> last step in the development caused an bug or not.
If you think of a test suite big enough to detect most bugs throughout
xconq, it gets really scary.
But the good news is that test suites are fairly easy to write one
test at a time (starting with the code you are about to tear apart or
feature you are about to add, for example).
I've written a few tests, but more contributions are welcome. Here's
the section I just wrote for the hacking manual. Running the tests
(or at least autotests) as described here would be a good first step
for someone thinking of helping out in the testing area.
There are a variety of tests, some more automated than others.
Running `make check' gets you all of them. Warning: some of them take
a very long time to run. Generally speaking most of the tests should
be interpreted to fail if xconq dumps core, and succeed in most other
cases (some error messages might be considered failures).
Perhaps the most interesting tests are the autotests. These are
written in a unit test style, meaning that the test code links into
the code under test, which is good for speed and makes it easy to test
particular parts of the code rather than end-to-end behaviors. They
should run fast enough to run them every time you make a change to
xconq.
To run just the autotests:
$ cd kernel
$ make skelconq
$ cd ../test
$ make check-auto