Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)

[Richard Frith-Macdonald]

On Friday, October 17, 2003, at 11:00 PM, Chris Hanson wrote:

> On Friday, October 17, 2003, at 02:08  PM, Alexander Malmberg wrote:
> > Why not? Running "make check" or "make verbose" in the test suite
> > directory isn't hard. Is the dependency on guile that bad?
>
> Actually, yes.
>
> In my opinion, the GNUstep unit tests should be in Objective-C just 
> like the rest of GNUstep.  This way it's very easy and straightforward 
> to write tests for individual classes, methods, and portions of 
> methods.  This is of utmost importance if you're going to do 
> test-driven development.

While I don't believe a dependencuy on guile is a disaster, I do agree 
that tests in ObjC would be better, and I now think I made a mistake in 
writing the existing testsuite in guile all those years ago ... the 
reason I did that was that the Free Software Foundation had writing a 
Guile based test framework on its task list.  I don't think it has 
served GNUstep as well as a simple ObjC based framework would have done.

> The test suite should also run every time you do a "make" -- you 
> shouldn't have to do a "make check" or "make verbose" to run them.  If 
> anything, you should have to do extra work to do a build *without* 
> running the full test suite.  A command-line argument to the testing 
> framework that tells whether to suppress individual suites would 
> probably work; that way, you could move quickly by only running a 
> subset of the suites when working on one particular feature, but very 
> easily run the entire suite to make sure you're not breaking anything 
> elsewhere.
>
> Every additional step (running "make check") and dependency (guile) 
> substantially reduces the likelihood that the test suite will actually 
> be used, much less used to do all new development and refactoring 
> test-first.

All sounds reasonable to me ... the problem is finding anyone with time 
to get this sort of thing in place .. it won't
be accepted by people unless it's pretty seamless.

> Doing refactoring and feature addition test-first helps you add unit 
> tests to an existing framework or product.  To do it, before writing 
> failing tests for the feature you're going to add, start writing tests 
> for the code that you're likely to touch in adding the feature.  Then 
> refactor that code, keeping the tests in tact and writing new tests as 
> necessary, so as to remove duplication and make adding the feature 
> easier.  Then do normal test-driven development to add the feature.
>
> The amount of test coverage your product or framework will get from 
> repeated applications of this follows an exponential curve.  You might 
> never get to 100% coverage (as you might have if the whole thing had 
> been written test-first) but you'll get *enough* coverage.