[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: cmh@bDistributed.com
Custom Mac OS X Development | Phone: +1-847-372-3955
http://bdistributed.com/ | Fax: +1-847-589-3738
http://bdistributed.com/Articles/ | Personal Email: cmh@mac.com