[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: |
Fri, 6 Feb 2004 06:09:01 +0000 |
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).
- Re: test driven development for GNUstep, (continued)
RE: test driven development for GNUstep, Adam Fedor, 2004/02/06
- Re: test driven development for GNUstep, Alexander Malmberg, 2004/02/06
- Re: test driven development for GNUstep, Richard Frith-Macdonald, 2004/02/08
- Re: test driven development for GNUstep, Alexander Malmberg, 2004/02/09
- Re: test driven development for GNUstep, Adam Fedor, 2004/02/10
- Re: test driven development for GNUstep, Alexander Malmberg, 2004/02/10
- Re: test driven development for GNUstep, Kaelin Colclasure, 2004/02/11