Testing Lets You Go Fast

When I was an egg, I always felt that testing was boring and a pain. I felt that it slowed me down. I wasn't as right as I might have been.

FunctionalTests, provided by your customers, can provide a wide range of testing situations and values to compare. You might have to give them a tool, but they can and should provide the values. When you're implementing new functionality, just run the relevant functional tests and see how you're doing. Much better than reading the spec, if there is a spec.

UnitTests, which you write, are a great way to go super fast. Need a new feature in your object? Write the test to see if it is there. Run the test. Hmm, the feature doesn't work yet. Develop that one small feature. The test says Good! You feel good. Write another test, make it work. You can build up a wonderful rhythm of test-do-test-do. Very easy way to get to flow and stay there. Right sized bites, positive feedback, feels good, makes flow. -- RonJeffries

"Tobin Harris" wrote in message news:<acd4mq$ophi2$1@ID-135366.news.dfncis.de>

Does anyone know if it's acceptable/viable to use test-first design on small projects. The argument so far is

Me> Lets first write some unit tests, and help reduce the defects by about 90%

Colleague> Yeah - and increase the project duration by 90%.

Me> I Disagree, unit testing only adds a little bit of time to the developent, compared to what it saves.

Colleague> Yeah, but unit testing is not really viable for small projects (2-16 weeks)

I have a car with a built-in radar system, and inertial dampeners. It can stop on a dime, before I realize there was a reason to stop, and it decelerates super-relativistically, so I don't get thrown around inside.

When I drive on the freeway I go 185 miles an hour. I never have to worry about hitting anything, or going too far.

But when I go to the corner inconvenience store, I go 375 miles an hour. Less navigating. What in the world?!

Test-first lets you go very fast because your code always accurately and automatically tells you exactly when to stop. So you are free to code and refactor much faster than with test-last. Stop adding test lines when they fail for the correct reason. Stop adding code when the tests pass. Stop refactoring (and Undo) when the tests spring loose.

The small projects just require less refactoring.

-- PhlIp

There are "obvious" examples that demonstrate that UnitTesting will slow you down. In the context of XP though, the claim is that any short-term inefficiencies are amortized over the life of the project: there are enough cases where the UnitTests save you, that it is better to always use the technique than to spend time on each case to worry about whether to use it or not. I'd say that the jury is still out. Remember that the XP rule is the test anything that could possibly break: not to test everything. That's a fuzzy line. -- DaveWhipp

See OneButtonTesting

CategoryTesting