[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Frith-Macdonald
Subject: Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)
Date: Sat, 18 Oct 2003 06:16:10 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]