Meanwhile, back with the tests

I’ve seen a lot of blog postings recently that pour scorn on the ideas behind TDD. Ah well, if you don’t like it, don’t do it. I’m more than happy if our competitors decide that TDD isn’t for them. In fact, testing is bad, don’t do it, move along now, don’t read any of the testing articles here…

The jarring of the “real world” work we’re doing is made worse by work we’re doing for another client at the moment. We’ve quoted them a fixed price to develop a framework for some servers they’re developing. We’re taking the latest and greatest version of the freely available socket server code and building some stuff on it that will allow their developers to simply plug in their business knowledge and get on with solving their problems. The fixed price focuses the mind on putting together a high quality system quickly. Luckily we have tests…

The work involves plugging together various pieces of existing code in a new way to provide the client with a custom solution that they can then extend. All of the existing code is of a known quality, much of it has tests, the work is going well but what I’ve noticed most this week is the speed of the “test, develop, test, fix, test” cycle. If the test cycle at the corporate client is like walking with your shoe laces tied together then this test cycle is like driving one of those cars out of The Fast and The Furious; I like my development with added nitrous oxide…

We’re pulling The Server Framework in a slightly new direction, as we pull, tests fail when we break things. Things are then fixed, or the tests are adjusted to reflect the new reality. The tests have made an amazing difference to the speed that we can react to new and different client requests. We’re shipping more code to more clients faster than before we had tests and the code is of a higher quality.

So, in summary, if you’re in the same market as we are, testing is bad, don’t do it, move along now, don’t read any of the testing articles here…