Shut Up, You Are Already Testing Your Code

As a foray into the second week of bidaily posts, I aim to make even more people mad about TDD. See, the first time you made a program you were doing some form of TDD. In fact, I believe that there is a psychological progression of TDD that you enter into from day one.

Mental TDD

The second you start thinking of what you want to program you are starting down the path of TDD. That visualization of your new plugin or how you want to interact with the plugin is the first step. Free on your own for the first time coming out of tutorials you see the vast landscape of whitespace and start carving out your code. Eventually, you get something that sort of resembles your mental picture and you call it a day. Green.

Mockup TDD

In all honesty, every web developer eventually has to tackle. Whether in a team, for a client, or for yourself, you will be presented with a wireframe, flow chart, or PSD file with what a site should look like an how it should feel. Your testing is the refresh button and Chrome Developer Tools. This is actually a form of TDD, the standard is set in place, it passes when the HTML, CSS, and JS look like the mockups. Green.

API TDD

This is where you start really looking at the architecture of your codebase. Working from mockups, feature lists, support tickets, or user stories, you begin to realize that you will write better code if you write the way you want to interface with the code first. In its purist form, this is Interface Driven Development, however quite often you will not start out by actually using an interface or inheritance pattern.

Functional TDD

Now we start getting into what many would actually categorize as TDD. You write functional tests for your code. However, it is likely that you are grabbing things out the database and testing all of your application logic at once. While extremely valuable, this poses some problems, especially with beginners who may not know that they should be using test databases with seed data rather than live data.

Unit TDD

Now we get to the elephant in the room. Unit testing is incredibly powerful. By mocking objects and testing every individual peice of your codebase, you have a secure blanket of warmth to live by. But, unit testing alone will get you only so far. In fact, it will drive you insane if you don't have an architectural plan to build these units into.

In fact, I have found that a well orchistrated TDD project implements all of these methods at one time or another. Clearly, there is a state of mental planning but it should be moved to paper as soon as possible in the form of mockups or feature lists. From there, you have to do some planning around where you need to go, for this I suggest using Interface Driven Design to forge a path ahead. These interfaces give you the perfect skeleton for coming in and writing Unit Tests for your code (it gives you an idea of what to mock). Then come in and write unit tests to check your code. Rewrite, refactor, and clean up edge cases as you go. Finally write and run Functional Tests for your logic to test that all of the Units are running the way you had planned.