I read an old blog entry by Cedric Beust about agile and test driven development (TDD) and I started thinking about some of his points. I agree that tests are not the specification for an application. They are tests. Seems simple.

I think what most Agile folks are missing is that tests form an additional component of the overall application that helps describe the contract of a piece of code. Contract and specification are different. Contracts are used only by developers and help to solidify and harden the code for production. They also help reduce headaches for the next dude who comes along and either:

1. calls into the contract
2. or modifies it

The tests help reduce pain for this second dude when he does #2 above. It does not help when he does #1 above. This is what JavaDoc is for. Especially if said dude doesn’t have access to the source (think offshore or decentralized development or open source or architecture nazis or security clearance or whatever).

A specification is used by managers and product dudes and marketing monkeys and everyone in the company who wants a say in the final product. Specification is something that is loosely technical and mostly business. If you want to talk about technical specifications solely, well than that’s different. Those are in depth manuals of how the code, architecture and components work and to me are very RUPpy. But they are still not the tests because they define parts of the application that tests don’t like IP addresses, multicast groups, routers, deployments, infrastructure, DNS and much more.

Cedric’s second point about the speakers statement: “testable code is worthless” I think missed the mark abit. I understand what we was getting at, but his examples and discussion revolved not around untestABLE code but untestED code. There is a HUGE difference.

UntestED code is not worthless. This is simple as well. It just didn’t get tested because of timelines or bad coders or dumb managers or whatever. The ideal solution is just to write some unit tests. Something else that Agile and XP tend to dislike is this notion of going back and writing tests. “Tests should be written first!” Yeah whatever dudes. This ain’t gonna happen with deadlines and customers and press releases about some new alerting system that went out before the code is written. Just live with it and start embracing the possibility that tests written after the code is written are equal if not better than the tests written before the code. You already know the soft spots! You just have to be man/woman enough to break your own code. Most of us have an issue with this and we usually test lightly after the fact because we are scared of the possibility of breakage. Again – grow a back-bone and realize that breaking code is a good thing! You can then fix it and now you have a test for it. I personally love writing tests after the code because I LOVE finding bugs. I love writing tests that just freak code out and make it barf. Then when you fix the code and polish everything up, you KNOW – I mean you 100% KNOW that your code just rocks the house!

Okay, back on track…. UntestABLE code is not worthless either, but should probably be carefully considered and usually rewritten so it is testable. This is really where as engineers we need to focus our efforts, not on writing tests first or even on writing docs or specifications or whatever. We need to focus on ensuring that we can test code when we have time. There are ALWAYS (that’s right kids – ALWAYS as in never gonna stop being – as in for eternity there will be) cases where you have some code that just can’t be tested in an automated fashion. Most folks understand how hard it is to test javascript in the browser and even harder to test javascript that effects CSS that could end up making the page look like crap. Try testing that in an automated fashion. Just not gonna happen unless you build a new piece of software that can understand human esthetic enough to look at a GUI and determine that it looks like dung. Yeah – good luck with that!

So, I think everyone who codes should go write tests and docuementation and the best code that they can under the conditions of the job. Even if it is two unit tests for 50,000 lines of code and four javadoc’d methods, still it is a start. Good luck and may the code be with you.