On Testing

This is definitely written from a developer perspective -- that is, after all, what my friend Alex is -- but his writeup here on the importance of testing and how to best do it is pretty sweet for anyone involved in product development. (Like, um, me.)

Any non-trivial problem needs to be broken down in some way. Few of us have the mental capacity to keep an entire solution in our heads. Even if we could, it generally doesn’t last beyond the period in which the solution is developed. And even if you could do this, chances are few of your teammates would be able to. So at worst, breaking a problem down is a pro-social practice; at best it’s a tool to ensure that you really understand what’s going both now and in the future.

It must be an inherent part of human-nature—we simply love putting things in boxes. Perhaps this is because that in doing so, we can hang a simple tag on a collection of related concepts as a form of shorthand. That shorthand allows us to talk about things in an efficient way. Imagine a design conversation where you couldn’t name anything, but had to describe a piece over and over by its details. Yuck. So yeah, boxes are important.

So where does testing fit in? Testing allows you to write automated assertions about each of those boxes. It’s like a logic game where you can start draw conclusions based on what you already know. It’s like being able to say, “If this test is passing and that test is passing, the only thing that could torpedo this is if that doesn’t work”.

Check out the whole post. Alex has really done a great job here.