Re: growth agendas and OO

[Jim Kingdon <kingdon at panix dot com>]

> 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