prose :: and :: conz


Use a computer to do your testing too

Software testing is undoubtedly my second-most passionate topic behind only Scala. In my mind, testing comes first but just look at my blog posts and twitter feed to see that it isn’t the case. I’m always surprised by how difficult it is to convince people in the software industry of the value (arguably necessity) of test-driven development. Recent code acquisitions at work show once again that many don’t regard testing as important. I know that TDD is a tired old topic to which I likely have little to contribute. However, I think I finally pinpointed the root of my surprise in a recent tweet, and I’d like to expound on it in this post.

When you are writing code, there is ultimately some problem you are attempting to solve. Writing code for a computer to execute may not be the only way to solve that problem, but nonetheless it’s the solution you have selected. Regardless of what tool you select, you open yourself up to a new problem. That is, does your solution actually solve the problem at hand? Even if you hadn’t elected to utilize a computer to solve your problem, you have to verify whether or not you have a correct solution.

Every developer worth anything will test his code at some point, even if not utilizing TDD. We all like to see that our stuff works. Some how or another, you get your code into a running state and stimulate the system in order to pass values through which you have an expectation for how it will react. This is a very laborious task, especially for large systems which take a substantial amount of time to build and deploy. Outside systems and state further complicate matters.

Interestingly, this is where many people decide to stop using code. The same person that thought writing code would be an awesome solution to a problem is now faced with a laborious, repetitious task and instead decides that writing code is not the best way to go. Dude, bro… Really?? It’s such a pain to get even rather trivial applications into a state where you can try out different inputs. As soon as you discover code behavior that’s a no-go, you start the process all over and manually re-enter your test cases. What we have is a repetitive, labor-intensive, annoying procedure. This is precisely the sort of thing computers are great for! Use them!

Is TDD the only solution to program verification? Certainly not, just as writing a program potentially isn’t the only solution to the problem. However, I’m willing to wager you won’t find a better solution than the discipline of TDD. Even as I’ve begun to delve into functional programming where the TDD thought process is a little different, I feel that this is the most important tool I utilize.

I know there is learning curve associated with TDD, particularly with learning how to write testable code and mocking out collaborators. I wouldn’t expect learning would a barrier either considering developers are generally a curious crowd. I just get surprised when the type of people who like to write code are the same people unwilling to utilize code to solve a problem well-suited for a computer. So what’s the hindrance? I really don’t get it.


Olde Comments
  1. […] it always seems to be the case, when you solve one problem with software you create another problem. Java properties are no exception. I’d argue it produces at least four problems. It’s […]

Tagged with: unit-testing (3), test-driven-development (2)