[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeal
Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)
Wed, 15 Oct 2003 18:55:09 -0500
On Wednesday, October 15, 2003, at 01:58 PM, Stefan Urbanek wrote:
I think, that if at least half of the effort devoted to writing test
suites (i am not against them) is also devoted to make gnustep more
attractive, it can also help to remove bugs and have a quality
Actually, "the effort devoted to writing test suites" should be spent
in *advance* of the features those suites test. This is called
When implementing a feature, you first write a simple test case for one
aspect of that feature. Build, the test suite runs including your new
test case, it fails because you haven't implemented the code to make it
pass. Implement the code to make the test pass. Build, the test suite
runs including your new test, it passes. Now refactor -- remove
duplication from the entire codebase including your new code. Build
again, the test suite should still pass.
Then do it again, and again, and again, until you've fully implemented
the feature. Write a test, make it pass, refactor. Write a test, make
it pass, refactor.
Then move on to the next feature. Write a test, make it pass, refactor.
This is the core of a talk Robert C. "Uncle Bob" Martin of Object
Mentor gives: *Testing is about specification, not verification.* In
other words, the tests specify the functionality you're looking for --
both with success cases and failure cases -- they don't verify that
things you've already written work.
And here's the benefit: Since you're eliminating most debugging by
doing this, you're actually going *faster* than you would be without
doing tests first.
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