[ODE] Code quality

[Dave Grundgeiger]

> On 2/5/07, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
>>  A reasonable start would be to require that any patch that is submitted,
>> provide a test that shows what's wrong with the code pre-patch, and shows
>> that the code passes post-patch. That test then gets added to the suite 
>> of
>> tests, which will slowly grow.

Jason Perkins wrote:
> FWIW, this is what the Mono project does
> (http://www.mono-project.com/) and it seems to work well for them.

Test-Driven Development is one of the classes I teach in my training 
business and is the only way I've developed .NET code in the last two years. 
I'm a huge, huge fan of TDD. The concept is so simple that when you first 
hear it described you miss how powerful it is. TDD seems like more work up 
front--it's so much easier (and more fun) to dive into fixing a problem than 
to code an automated test to demonstrate the problem. But that automated 
test tells you when the bug is fixed and then becomes part of your automated 
regression test suite. I encourage my clients to do continuous builds, which 
means having the builder run automatically after every commit and then 
automatically run the unit test suite after a successful build. The benefit 
is that developers are notified immediately not only if the build is broken, 
but also if functionality is broken. And since it's done on every commit, 
the change that broke the functionality is usually quite small and easily 
addressed. A large suite of regression tests also gives you the confidence 
to refactor components that you might otherwise avoid touching. Code quality 
increases over time as you accumulate more unit tests and have more freedom 
to refactor poor code. Without TDD, the code quality in large projects 
invariably deteriorates over time.

Did I mention I'm a huge fan?

Dave