[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
where.
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.
- 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
- Re: test driven development for GNUstep, Adam Fedor, 2004/02/12
Re: test driven development for GNUstep,
Richard Frith-Macdonald <=
Re: test driven development for GNUstep, Lars Sonchocky-Helldorf, 2004/02/11