CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Steve Hebert's Development Blog

Steve's Blog - From .Net to dotMath and everything in between.

.Math, TDD and moving from beta to version 1.0 release

This weekend I started writing testing code under NUnit for the .Math project.  Now I know this approach is completely backward, the original product was written in '97 and development didn't proceed using TDD/Agile methods.  However,  I think the long-term quality of a product with the flexibility of a compiler can benefit from a testing set.  This, of course, allows for a full test of the capabilities after making any mods/feature additions/bug fixes. 

I'm starting with a backward approach - I realize this and it's unfortunate but a reality of the product state.  I'm first testing the compilation results to make certain each function and operator is being evaluated properly.  Then I'll drill down into the individual areas of the application - the parser, the support classes, etc..  I'll post the test code on the download site when it's available.

I think this is the only way I can certify a release as complete.  This way anyone can grab the test suite and see the compiler is capable of performing the promised tasks.  I got the idea from the NUnit site.  I really like their Coding Standards stating:

“Test-Driven Development. This is non-negotiable. There will be no code that is accepted without associated tests. Also, we expect that Refactoring is part of your everyday activities so if there is a need to refactor do it.”

Bottom line, I believe that software quality is a reflection of the developer.  I think a TDD set is reasonable a way I can be confident in telling others the product is ready to be called a  non-beta release.


Published Jun 06 2004, 05:46 PM by shebert
Filed under: ,

Comments

Steve Hebert said:

Thanks Darrell,

The backword approach has some benefits that I didn't intend upfront, but they're paying off. First and foremost, I have an immediate degree of confidence in the application execution and visibility of any problems being introduced by any code changes. The code isn't changing much at this point of the release cycle, but it's nice to perform the test and leave out the guess work. I'm looking forward to instrumenting the core components next.

I did another blog entry on this work at: http://dotnetjunkies.com/WebLog/sdhebert/archive/2004/06/08/15828.aspx
# June 9, 2004 2:14 AM
Check out Devlicio.us!

Our Sponsors