Re: test driven development for GNUstep

[Richard Frith-Macdonald]

On 6 Feb 2004, at 16:15, Alexander Malmberg wrote:

> Adam Fedor wrote:
> > > Just loose thoughts but ...
> > > We *could* go down the route of writing each testcase as a small ObjC
> > > code fragment ... then we
> > > wouldn't really need a test framework at all ... just a makefile and
> > > the test code.
> >
> > I was actually just looking at how gcc does their tests and it appears
> > that in Objective-C, they essentially do this and just use DejaGNU to
> > compile and run the programs (and perhaps format the output?). We 
> > might
> > as well write our own simple framwork to do that if that's the route 
> > we
> > want to go, though.
>
> Which is basically what I've been toying with. I've released a basic
> version at:
>
> http://w1.423.telia.com/~u42308495/alex/AlexsGNUstepTests-0.1.tar.gz

Pretty much exactly what I was looking for.

I'd ideally like such a framework to be part of the GNUstep-make
package so all developers would automatically have it available
(with the actual library specific testcases bundled with the libraries).

I think it would be nicer if it had more sophisticated make-based
dependency checking so that it could build the binaries and keep
them around for the next testrun rather then rebuilding each test
from scratch each time round ... but that's just a performance/usability
issue, the system seems quite functional as it is now.  I think you
already have ideas along those lines anyway.

> To write a new test case, just drop an .m file in any (new or existing)
> subdirectory. Each test is compiled and run by itself, so it should
> contain a main function that does the testing. Exiting successfully
> gives you a 'COMPLETED', exiting with a non-zero exit status (or
> crashing, triggering an assertion, or throwing an uncaught exception)
> gives a 'FAIL'. If you want to, you can #include "Testing.h" and use 
> the
> pass() function to print PASS/FAIL messages for "sub-tests" and always
> exit successfully.

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.  It might be nice to 
preprocess
the source code to determine what tests should be run, and report the
tests which were not run.