*I really hate long blog posts, but this should be an exception to future posts on this topic*
Where’s TDD Day 1? It doesn’t exist. Why? Because I decided to start writing about my experience after day 2.
I’ve read countless studies, testimonials, love letters, etc about how TDD and how awesome it is. I’ll confess, I’ve tried it before – only to fall flat on my face at every turn of the road. I’ve read tutorials, books, blogs, and articles, but it’s never clicked for me. It’s one of those skills I wish I had, tried to attain, and realized that I just suck at this. But like all things, practice makes perfect. For the time being, I’m simply going to be writing tests, then writing my code. In my previous attempts at TDD or just unit tests in general, concepts like mocking made sense, but when it came time to code, I could never get it to work. So…. in the meantime, mocking is taking a back seat to simple stubs.
I’m not against TDD. In fact, I’ve fallen in love with just simple old unit tests. I’ve seen their benefit when a change I made broke code elsewhere — important code. With the few forays it’s taken me to write my code and try to do it in a TDD fashion, I have had the chance to place my stamp of approval, and that’s an unbelievable feeling. When someone questioned my code, I had the ability to say “No, I know for a fact that it does this and not that” as opposed to the usual “It should be doing this… let me run it and check just to make sure.”
In college they tried to teach use to write unit tests. However, the manner in which they represented it was complete and utterly useless. For example, they’d have us write a test to verify that adding two numbers equalled what we expected it to. Sure, this is a great toy intro test, but in the long run, those learning have no idea why you would write four fold the amount of actual code to test cold hard facts, such that 2 + 2 = 4. Programmers are lazy – it’s what makes them efficient, so as a result, it’s a skill that goes unlearned and never practiced.
Tell a manager that your code will take 40% longer to write and see what happens. You’ll likely get the response of “yeah, I don’t think that’s a good fit for us.” Only to spend an entire week testing medial code to make sure it didn’t break something somewhere else – and doing it by hand, which everyone knows is prone to more human error than code error. There is merit in human testing – but there’s a fine line in testing something that could be done automatically. The studies have shown that although it takes longer, maintenance time is cut and code quality improves.
Maybe you don’t like TDD or agree with it. That’s fine, but at least recognize the usefulness of unit tests. I remember sitting in an Asp.net MVC user group when a speaker said “we’re all doing testing right?” and the silence in the room was like a black hole. This speaker was mostly a Ruby guy and luckily, this was around the time when I started toying with Ruby and Ruby on Rails.
I’m a complete noob when it comes to dynamic languages like Ruby and Python, but I’m getting better. What I especially enjoy is the culture of those communities and how they embrace these methodologies which we should all be doing. For example, I know Rails is very opinionated – but in a good way. If you don’t write tests for example, you’re an outlier – but people are willing to help you out. Maybe its the fact that there’s no type safety in dynamic languages and it leads to insecurity about code. Whatever it is, I love it. I love that I suck at it, and I love that it gives me room to learn and grow.