My TDD Analogy
Posted on June 3rd, 2009
In my post about Test Driven Design I expressed concerns around building your entire architecture to just support testing. My thoughts were definately tough to put into words, maybe I should have used more pictures :)
I do finally feel I have a decent analogy to the problem I’m concerned with. Building your application to be perfectly testable would be like building a car to always pass a crash test and to say – “let’s build a car that could never ever hurt someone”. Great, so it has no wheels or even an engine but dammit, it performs great in crash tests, it passes every test!
Applications have to work, testing like vehicle safety does unfortunately come second to functionality. Should you test? of course – but it is a balancing act so don’t get sucked into all the hype.
Also, in the words of Jeff Atwood, don’t just listen to me or don’t listen to me at all. I am no expert so do your homework :)
Tags: TDD
Filed under Software | No Comments »
A warning about test driven development
Posted on June 1st, 2009
Oh wow did someone really say something bad about TDD … I mean what could be bad about this latest fad ;-)
So testing your code is of course a good thing. Anything these days to help us write better code is a good thing but definitely in moderation. I’d say with all the work going into TDD and I’ll later explain my thoughts on DDD, people are once again on the search for the holy grail of software engineering. It doesn’t exist, get over it – software engineers are artisans by definition and that is because our skill is extremely creative and you can’t wrap it up in a process to make it perfect.
What bothers me with TDD is the amount of effort being placed on “passing the test”. It is one thing to make your code easier to test but a totally different thing to engineer your entire application, just so it can be tested. Is your client paying you $$ per hour to have something that can be tested or something that works?
What about dependency injection. A hot subject for allowing the injection of mock objects or testable objects into code. My question is, if you inject a mock object into a test – is the test really real? Now inversion of control has its place, like most patterns, but I warn you against thinking you’ll now have perfect code if every class is instantiated through an IoC container.
So when it comes to application architecture I urge you to use some common sense. Pick patterns that solve problems you really have. A lot of code can be tested just fine without DI. A facade is often simpler for centralized code. Here are the general rules I would suggest to keep you on track:
- Build an application that meets the requirements first!
- Make sure it performs and scales well.
- Make it easier to test! but not a requirement if it means major architectural changes.
- If you can’t automate your test, like many user interfaces – use a person, they’re called QAEs!
You don’t have to like it but too many developers forget what the point of the code is to start with. Not to pass tests but to do something cool :)
Tags: TDD
Filed under Software | 1 Comment »