[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test driven development for GNUstep

From: Richard Frith-Macdonald
Subject: Re: test driven development for GNUstep
Date: Wed, 11 Feb 2004 08:27:56 +0000

On 10 Feb 2004, at 01:17, Alexander Malmberg wrote:

Richard Frith-Macdonald wrote:

I'd ideally like such a framework to be part of the GNUstep-make
package so all developers

By developers, do you mean all developers working on GNUstep, or all
developers using GNUstep?

My preference is all developers using GNUstep ... I think it gives a sense of security to people if they can readily see the software passing a load of tests (and probably makes it easier for them to contribute new tests).
IMO a major reason that the current testsuite seems to be little used is
that it needs to be downloaded and installed separately.

It would be nice if anyone building GNUstep from source was able to do
'make check' to confirm that everything is working before they do their
'make install'. or perhaps to have a 'checkinstall' target which would
build the library, run the tests, and install only if all the tests passed.

would automatically have it available
(with the actual library specific testcases bundled with the libraries).

I think I prefer a standalone core/tests/. While the framework is nice
and small now, a "testing backend" and support for generating event
sequences and doing matching on the rendering output will take a fair
bit of code, and that wouldn't belong in -make. Also, I already have
testing code that's needed for both -base and -gui (NSCoding tests, some class cluster tests that have concrete implementations in both -base and
-gui), and that doesn't belong in -make, either.

I would have thought that extra features could be added to a basic framework in order to support specific libraries in much the same way that it happens with the make system now ... when libraries are installed, their additional makefiles are installed in a subdirectory where the make system can automatically
find and include them.
That way a simple, lightweight test framework could be available to everyone, with extensions put in place as required. There ifs great virtue in trying to keep
a core system as simple as possible.

Just one thing ... if a single .m file does multiple tests and bombs
out at
the start, you don't get a report of the failures.

You do get _a_ failure report, which I think is the most important part.
You'll know which file it was, and the log will tell you approximately

Yes ... I think it's more important to keep the system clear and simple
than to add features.  On further consideration, I can't think of a good
way to report all tests which failed due to the failure of an earlier test -
the complexity of such code outweighs any advantages.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]