discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: Chris Hanson
Subject: Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)
Date: Fri, 17 Oct 2003 17:00:15 -0500

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.

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.

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.

  -- Chris

--
Chris Hanson, bDistributed.com, Inc.  |  Email: address@hidden
Custom Mac OS X Development           |  Phone: +1-847-372-3955
http://bdistributed.com/              |  Fax:   +1-847-589-3738
http://bdistributed.com/Articles/     |  Personal Email: address@hidden





reply via email to

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