Way back in August or something, I started to rewrite my forum app for the bazillionth time as an ASP.NET MVC app. After doing the blog earlier that spring and a few science projects, it seemed like a solid and non-trivial thing to do, and it was something I knew I'd use. I wanted to do it in a "real" test-driven way as well, because it really is something that takes practice.
I never did get around to doing much with it, as life just kept getting incrementally busier. But recently, a couple of nights last week, and then last night and tonight, I started to revisit it. I couldn't tell you when it might be done (I'd love to refresh CoasterBuzz by the end of the year, but I'm not sure that's remotely realistic), but it does go pretty fast.
I'm not doing 100% pure test-driven development, because sometimes the design comes to mind first and I just want to hack it out, then write the tests. I know the purists like to call you names when you do that, but whatever. I just can't be that dogmatic about a process that is inherently creative. The spirit of test-driven development is that it forces you to design code that does just enough, and is abstract enough to exercise in isolation. When you do it enough though, that design starts to feel natural, even if you're not writing tests first. But whatever, the ideological "debate" around that is not something I'm that interested in. What excites me is the ability to change and refactor and know exactly what the impact is. Amazing how concise you can be even when you've got a bunch of stuff throwing NotImplementedExceptions.
At work, unit testing is harder, because our primary app was written without tests. Plus it was poorly written. When I say poorly written, I mean everything is tightly coupled with crazy dependencies and it's hard to get any little piece isolated enough to test it. That's thoroughly annoying. On the other hand, our profile app was written from scratch, and it's remarkably easy to change and maintain.
At the end of the day, the thing I like most about unit testing is how high the quality of your code is, if you're doing right. While test code can out-do production code by a factor of two to one, I also think there is a huge cost savings in long-term maintainability and ease of change. That, and everyone loves a row of green lights.
Unit testing can be a godsend, especially in the early stages of development before you have enough complete pieces to pull them together for testing.
Of course, on large projects like the one I'm working on, you can run into a different problem -- we had extensive unit tests at first, and tested the hell out of the low-level stuff.
Now we're up against a deadline, and the unit tests have fallen by the wayside in favor of fixing the real-world bugs and getting it out the door. The tests that exist still pass, but they're stale (except in a few cases, where they won't even compile due to signature changes).
The purists will of course say "you didn't write sufficient tests", but c'mon, you can't anticipate EVERY real-world scenario, and if you try you'll never ship anything.
Yeah, that particular issue definitely is a failure in how we follow the process (or not). That comes down to while under pressure, a few developers were able to convince management that updating the unit tests as we go would cause a delay, so the "run unit tests" requirement was suspended.
Earlier, we'd have never gotten anywhere WITHOUT unit tests given the scope of the project, so I find that somewhat ironic.