Re: test driven development for GNUstep

[Richard Frith-Macdonald]

On 6 Feb 2004, at 00:34, Lars Sonchocky-Helldorf wrote:

> Am Donnerstag, 05.02.04 um 23:53 Uhr schrieb Adam Fedor:
>
> > > -----Original Message-----
> > > From: Alex Perez
> > > On Mon, 2 Feb 2004, Adam Fedor wrote:
> > > > The only disatvantage is that we already have 2000 or so
> > > tests written with guile...
> > >
> > > Maybe we can all volunteer to rewrite a few of the more
> > > important ones
> > > first?
> >
> > Sure. In fact, there are a set of tests that are run on every class. 
> > Many other tests are very similar, so perhaps someone could hack 
> > together a simple parser to translate guile to Objective-C?
> >
> > We should probably settle on what kind of testing framework we will 
> > use first...
>
> From the ease of use I'd prefer OCunit but I my knowledge is not 
> funded enough to know if there would be technical obstacles that would 
> prevent us from using it (that is for testing GNUstep classes itself 
> not work based on GNUstep).

I don't know OCUnit ... can we distribute it with GNUstep?

> If OCunit is not usable for this purpose I would strongly recommend 
> using DejaGnu since it is widely proven to work. For instance GCC uses 
> it. You can simply run it as part of the make process (make -k check). 
> It even has the capabilities to send the test results somewhere. I 
> haven't written a DejaGnu test myself yet but since all those GCC devs 
> use it regularly it surely doesn't require you to have a PhD - and 
> there are already some ObjC tests to learn from.

I'm strongly against DejaGNU as it is considerably worse to use than 
our existing test framework ...
the existing stuff was written as a replacement for earlier 
DejaGNU-based code.
The problem was not so much with the test framework itsself but with 
the linkage from the tcl
code to the objc library code (which made it very difficult to track 
problems with the tests into
the objc code) and the difficulty of making complex tcl code 
reliable/robust/readable.

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.

Imagine, we could have some simple makefile rules to ...
1, take a file with a .fragment extension and incorporate it into a 
template file to produce a .m file.
2. build the .m file to an executable using normal make rules.
3. run the executable and send its output to a file.
The make dependency rules would ensure everything was done in the 
correct order.

The convention for the fragment file could be that it contains 
something like ...
// BEGIN
- (BOOL) testPasses
{
}
// END
Where testPasses returns YES on success, NO on failure, or raises an 
exception

The template file would contain all the supporting code to execute the 
test, catch exceptions,
and produce output.

If making each test a separate program is too slow to run, we could do 
them as bundles
with a single program to load and run all the bundle code (which would 
be easy to run
under gdb and track down problems).