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.

Comments

Popular posts from this blog

Review of the New Macbook

I finally got a chance to give the new MacBook a whirl and decided to share my thoughts about it. I very rarely feel compelled to review products or services. Like the average consumer, I typically only review things when they’re so fantastic that I think they’re a real game-changer or, conversely, when they’re so terrible that I think it’s very likely they’ll be a game-ender. Unfortunately, this review will be the latter - let’s begin:

The Big Question Admittedly, I was skeptical about the new MacBook from the get-go. Despite my skepticism, I really do like to give everything a fair chance, so I tried to keep as open of a mind as possible. Rather than focusing on any specific feature of the MacBook and making an uninformed decision about whether or not I would like it, I instead simply pondered the question “who is this designed for?” Unfortunately, after spending some time with it in person, I’m no closer to answering that question.

And that really is the big question - the only on…

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 quick and dirty …