So here's the thing about test-driven development. I think it's awesome because it forces me to be more focused in my design and I know when I break something if I have to revisit it. But I suck at it.
I test too much or too little. Sometimes I write tests after the code because I want to get something working quickly. I don't break things into small tasks like I should, and I let big picture temporary roadblocks slow me down.
The bigger realization that I've come to is that TDD is amazing and awesome for back-end development. When I was first exposed to TDD, it was in an environment that was 100% executing code with no UI, like mainframe replacement stuff. Indeed, this development methodology is a big deal because you really don't have any other way to understand and be sure that the code you're writing actually works.
When you're building a Web app, especially on the considerably smaller scale involving a team of one, TDD can get in the way. A lot of the time, I want to hack out some UI and start to drive my requirements from that. And if you think about it, that really makes more sense, because the UI helps define the solution to the business problem you're trying to solve. I'm sure that some consultants would freak out hearing me say that, but it's so true. The UI is something tangible up front, not a bunch of abstract bullshit that won't actually translate to something useful.
That said, there are a lot of cases where TDD makes sense even in this scenario, because it provides a great apparatus to make sure what you're doing works. It's great for testing (and maintaining) data access code in particular. It also works great for making sure some kind of calculation or text manipulation performs as expected.
So as is the case with most things in life, I'm finding the all or nothing approach using a particular methodology is just not practical.
No comments yet.