Expanding Your Workflow

An experience of being wrong about TDD

I’ve been coding for a few years now. Self-taught for the most part. While teaching yourself has its benefits, you can fall into “unhealthy” routines and workflows. This is my experience with test-driven development (TDD).

I don’t need to do that. It’s a waste of time…

TDD is not a waste of time. TDD is essentially adding one and a half new steps to your programming workflow: writing tests (1) and eliminating redundancies (.5). You should already be eliminating redundancies in your code (which is why I consider it only half a step), but outside of TDD it can be hard to tell when to step back and refactor. Do you do it after writing every new method? Do you do it after everything is working?

In TDD you do it after you pass every test. The workflow looks like this:

Image courtesy of: http://www.firebearstudio.com

Which leads me to the big new step in my workflow, writing tests. I thought that writing tests were a huge waste of time. Why spend the time writing tests when you can test them yourself? Aren’t my programs going to be used by people anyway? Well actually, after the initial time investment of writing the test, I found that TDD actually saves me time in the long run. Here is an example: Let’s say I have a simple program that asks the user for some input about movies and then saves it to a database. The program starts and,

  1. Asks the user for a name
  2. Asks the user for their age
  3. Asks the user for the most recent movie they’ve seen
  4. Asks the user what they would rate it from 1–10
  5. Asks the user for the next movie they are planning seeing
  6. Save to database

So if I’ve already coded the Command Line Interface and input questions, and am now writing the save to database step, when I go to test it manually I have to type in an answer to every question again and again and again. If the save to database step is complex, I could be wasting a lot of time retyping my input over and over and over again. TDD gets around that by letting us preset our model to a specific stage before the test runs. So I only have to write the responses once, run the tests, and I get to my save to database step immediately. With complex codebases TDD can actually end up saving me a lot of time!

I don’t need to write tests, I’ve been coding just fine without them…

I’ve discovered that tests serve a larger purpose than just “testing” my code as the name suggests. In TDD we write the test first, and then we code, not the other way around. My high-school computer science teacher told us to have a “ready, aim, fire” approach to programming, and that we were stuck in a “ready, fire, aim” mindset. I’ve realized that TDD is the “ready, aim, fire” approach in that by writing our tests first, we are inadvertently “aiming” by planning ahead with our code. We plan out what each test/method should do before we actually “fire” (code it).

And sure, I’ve been coding just fine without using TDD…but a key point in programming is finding the best and most efficient way to accomplish our tasks. I’ve already written how TDD can save time and help us better plan our our code structure, and it can only make me a better programmer…so I think it’s time for me to swallow my pride and start incorporating it into my workflow.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.