[ODE] Code quality
dave.grundgeiger at codenouveau.com
Tue Feb 6 09:57:58 MST 2007
> 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
>> 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?
More information about the ODE