TDD is hard. It sounds like it wouldn't be hard. It's just a little test. The code is the hard part, right? But it's really hard to do it well. I struggle with it plenty and I know my way around C# and OO pretty well.
There better be a payoff for this bass-ackwards way of coding. It takes a while to get there, but I can see the light at the end of the tunnel in my own development. Here's where I've seen my code improve as I've moved toward TDD:
Focusness
You focus on the behavior of your code instead of the implementation. You don't start by thinking of tables, classes, and properties (or in my case, try hard not to). You start off thinking of the business requirements and roles. User stories are popular because they push you into restating the requirements in context: "As a (some role)...I want to (do something)...so that (some business value)". The first two chunks of this can guide your test creation. You can write methods that cover these scenarios.
If you're doing it the RED-GREEN-REFACTOR way, you'll write a test and just enough for the code to compile, get the test to pass with the minimum amount of code possible. Finally, you can go back and clean up what you aren't proud of from your first effort, then run the test again. You get to keep repeating that until you are happy with the code and that the requirement/story is met and the user accepts it.
Then you STOP. That's the fourth step you don't see in the pretty RED-GREEN-REFACTOR icon. If you don't stop, you loose your focus on the functionality and you start trying to gold-plate the code. Which can lead to...
Dude, you know what would make this REALLY cool?
You're getting paid to write software to meet the requirements. If you going beyond that, be careful who you're doing the coding for. If it's the business, and you're glad to show them how much time you've spent on it, you might be justified in doing it. But if you're coding it for yourself, do it on your own time.
Unfortunately, people who are drawn to programming are often tinkerers and bit-twiddlers. I appreciate having a framework for my development that keeps me on task, because I am easily distracted by grand visions of what I might be able to code into the app. There is no code we couldn't tweak a little and add this new cool pattern or just-learned technique to. TDD forces you to go directly to the requirements, not the technology.
SOLID code
The more you move toward TDD, the more little classes you have with giant names. Same thing with methods. There are tons, they are very short (one screen or so max), and they have long names. This is progress?
Yes, I think it is because of the SOLID principals. SOLID is a horrible acronym of acronyms, but it can help you keep some object-oriented principals in mind. I'll go over it and how I've tried to learn it in more depth in a future post, but the guys at Los Techies covered SOLID in depth already. So the side effect of decoupled code is you have lots of little files that just do one little thing. It took me a while to get over this and the file bloat in the project, but I'm at peace with it now. The payoff is that I am using more SOLID principals than I was before, and that's a good thing.
Oh yeah, you get some tests, too
It's been said before, but TDD is kind of misnamed. Yes, you start with the test, but that's not the most important thing. The most important thing is the requirement focus and the way it drives you toward a more loosely coupled design. But it's pretty fun to see that screen light up with green checks or circles after you've made a change.
The real value of the tests themselves is that today's unit tests become tomorrow's regression tests. You won't remember why you wrote the code last week, but you don't have to. The tests can also serve as mini-documentation of the requirements if you write the test names in a consistent way. There are BDD frameworks that let you spit out some HTML to do exactly this.
Ruthless Refactoring
All this adds up to something of a safety net for refactoring. Think of the confidence you can have changing the code, even if it's another team members code. Or if (gasp!) they make changes to your code. It's nice to know your code still works.
If you write the tests first, you know you've got the "happy path" covered on your code. That's the one you started with. You can write a few more tests to cover the likely deviations from that happy path, but when you get to the weird stuff (what if you order $999,999,999,999 in widgets?), call it good and move on.
