Skip to main content

Test It Real Good

Test-driven development blows but, fortunately, that is not all.

The above tweet from a week ago was my first, extremely honest, impression of test-driven development (TDD). Clearly, I wasn't too thrilled with it.

I was briefly exposed to TDD when I began exploring the wonderful world of Ruby on Rails (RoR) a few months ago but, seeming like an extremely tedious endeavor, I decided to just glaze right over it and get into the "good stuff" with RoR. Knowing that we would eventually be diving head first into TDD in our class, I have been absolutely dreading the inevitable since I first got accepted into The Iron Yard Academy.

And right off the bat, it didn't disappoint (didn't disappoint my expectations, at least). It was exactly as tedious as I had thought it would be but, believe it or not, I actually intend to argue strongly in it's favor today. First, I've got to explain why it's obnoxious to me - I'll use an anecdote.

When I was a kid, I had accumulated a little bit of money from several months of allowance. At the time, there were several incredibly important items I wanted to spend that money on - plastic army men, Legos, Fun Dip, etc. However, I had observed from my dad that in order to go into a store and buy things, you needed a wallet to carry your money. So, naturally, I decided that I needed to get a wallet but I was shocked to find out that wallets cost money! I genuinely struggled to comprehend the seemingly-backward concept of having to spend money on a device that would carry your money. After all, if you spent all of your money on the money-carrying device, you wouldn't need it anymore because there would be no more money - quite the catch-22 for my young mind.

My initial reaction to TDD was roughly the same. I want to write some code for an application. To do this will cost me my time and brain-power - a resource that I consider much more valuable than anything monetary. But wait, now somebody is telling me that I need to do something else that will cost me time and brain-power to make the necessary preparations for expending more time and brain-power...WHAT?! This logic truly broke my brain.

Don't get me wrong, I've been doing development for several years and am a huge advocate of strongly testing an application that you develop - as everyone should be. In fact, even before getting introduced to TDD I would have considered myself to be a meticulous and thorough application tester, but the concept here is totally different.

For any applications I would have written previously, testing would have mostly been an afterthought. Aside from building in "tests" to verify form components, such as making sure a text field that was supposed to be a five digit number was indeed a five digit number, I would pretty much decide on the things I wanted to test on the backend of development. And to be honest, many of those tests were built on just running the application and watching it fail - very professional!

I think one of the big reasons that TDD is a daunting mental exercise is because "test-driven development" is kind of a misleading moniker. For one thing, you will still need to run backend tests as well. Even with making heavy use of TDD practices, you'd inevitably release a really crappy product if you didn't do any end-to-end testing after completing your development phase. Furthermore, in what world does testing the capabilities and limitations of an item make sense before the item your testing exists? That'd be akin to asking someone to verify that a chair could support a 400-pound individual before the chair was built. Sure, you can crunch the numbers on how much force four pieces of 1-inch thick, turned maple can withstand, but until you've had a 400-pound individual sit down in that chair and confirm that it won't collapse, your chair really hasn't been tested.

What TDD really helps you to accomplish beyond the traditional idea of "testing" is to think, to plan, to design your code instead of just letting it unfold in a syntactically-drunken stupor. Truly, it makes you write better code - code that is configurable, extensible, and much more solid than what you'd have come up with otherwise. It forces you to decide some things up front:
What do I want to accomplish with my code? 
How should my code function?
What kind of things do I need to verify to ensure that my code functions correctly?
These are all incredibly important things, yes? Surely, even if you'd never heard of TDD, these are all items that any seasoned developer would stand behind.

My biggest complaint from the get-go was how backwards it seemed to me that I have to write code to test my code - i.e. I have to debug another chunk of code, that's supposed to be helping to debug my other chunk of code. It definitely is an awkward "chicken or the egg" scenario, but when you look at it from the standpoint of planning, self-documentation, and stating up-front your design intentions, it makes perfect sense. In fact, it makes you wonder why you'd ever write an application without it.


Popular posts from this blog

MailSnail Series

Starting in August of 2015, I began building a company called MailSnail with my friend and co-founder, Matt Bertino . To follow along with my personal thoughts on the ins and outs of the company, experiences, lessons learned, technical details, etc., please check out the posts below. I’ll continue to add new posts here as I publish them. Post 1: Starting a Company Post 2: Building a Product Post 3: Launching a Product

Building a Product

This is the second post in a series I’m writing about a company I’m starting up (or have started, depending on when you’re reading this). You can read other posts in the series here . As I’ve talked about here , I’m starting a company called MailSnail . In this post, I want to share the ins and outs of how we’ve built the product (i.e. the actual web application). The Buzzwords I’ve tried my hardest to make this post as approachable as I possibly can for anybody and everybody. I don’t want this to be something that is only interesting to folks who know what HTTP stands for or can rattle off it’s associated status codes. So for my non-tech readers, please bare with me for this one section and keep on reading. For my fellow tech-nerds, I figured you might not care so much about the minute implementation details but rather are just more interested in a list of all of the pieces of our tech-stack (because you already know the implications of each in their use). So here’s the qui

Working from Home - Privilege or Necessity?

If you’ve spoken to me at any point in the past 7 months, there’s a good chance you've heard me mention the fact that I love my job. If not, then here it is - I LOVE MY JOB!  It’s a great company, I’m doing cool work, I work with two awesome, talented devs, and I’m able to challenge myself and learn new things on a daily basis. As of a couple of weeks ago, my boss declared that we were enstating a new policy - WFHF (Work From Home Friday). To him, it was a no-brainer - a simple, easily-enstated perk that doesn’t cost the company anything and in no way hinders productivity. In fact, it can actually increase productivity - but more on that in a bit. There’s no doubt about it, being able to work from home every so often is certainly a privilege - one that I’m extremely thankful for. But I also think that it can be an absolute necessity, which more companies should embrace as a means to secure their foothold in their respective industries. Let me also state right up front, I com