Akshay is anxious to have cutlets. He can’t wait to sink his tooth into the cripsy, brown delicacies. He  quickly boils some potatoes in a pot, mixes them hurriedly with some chilly, salt and pepper, pats the mixture into round shaped patties and sautes them on the pan greased with oil. Finally, he eats them. Oops. The potatoes are only half-boiled. He has added too little chilly, too much salt. The oil had not heated properly before Akshay tossed the cutlets in it for shallow frying. Some cutlets are still raw. Akshay thinks to himself: “Next time I should test the results after each step of cooking.”

Bharani is more methodical. She starts with a skewer. The skewer bounces off the surface of the potato. “So this is how hard they are”, she thinks, “They need a 10-minute boiling. After that, the skewer should go 2 inches inside”. After the potatoes are done, she tests with the skewer again and is satisfied with the texture. She mashes them and puts a small sample of the mash into her mouth. The bland taste gives her an estimate of how much spices should be added. She starts with a teaspoon of chilly and salt, kneads the mash well. After 10 seconds of mashing, she tastes a sample. She adjusts the chilly and salt as per her liking and then pats the mash into round shaped patties. Next she heats some oil on a pan. She waits until the oil sizzles. Then she drops a tiny piece from one of the patties and checks how it fries. The piece comes out golden brown and cripsy. Now Bharani is ready to lay all the patties on the pan. In the end,  she enjoys some tasty cutlets.

What is test-driven development?

Test driven development is a method of writing software. In this approach, the programmer writes all the test cases before he writes the functioning software. The test cases set an expectation of how the software should work. Thereafter, the software is written to match the expectation of the test cases.

Test-driven development (or TDD for short) reverses the traditional process where tests were written after the functioning software was written. Previously, tests were for verification only. Today, tests set expectations for how your software should be designed.

How does the process work?

Bharani follows test-driven cooking. Let’s take the skewer example. She sets a test with expectations: the skewer should go two inches into the potato. Before she starts the boiling process, she carries out the test once, expecting it to fail. Sure enough, the skewer bounces off the potato. This assures her that her test itself is reliable. She repeats the test after boiling the potatoes and this time the test succeeds. Note that her next test, i.e. tasting the boiled mash, comes before the next step in her recipe, i.e. mixing the mash with spice. She starts her cooking with one and only one test, followed by only one process that would make the preceding test pass. Here’s what her execution looks like.

• Skewer bounces off potato (test fails) – Boil potatoes – Skewer pierces two inches into the potato (test passes)
• Mash tastes bland (test fails) – Mix chilly and salt – Mash tastes spicy (test passes)
  … and so on.

Unlike Askhay who did too many things without waiting to test their outcome, Bharani has guarded each step in the recipe with a test that MUST succeed before proceeding further.

This is exactly how TDD works. The programmer writes exactly one test for a software function he/she is about to write. The test is run once to make sure that it fails. This assures the programmer that the test itself is reliable. Next, the software function is implemented. The test is run again, but this time, it should succeed. Only if this test succeeds shall the programmer move onto the next functionality.

How complicated is TDD?

TDD is extremely simple. In fact, following TDD is easier than the traditional approach, since all the test cases are covered before-hand and you don’t have to remember them as an after-thought. The same programming languages and tools that are used for writing traditional unit and integration test cases are also used for TDD. It is just that the tests are written before the functionality is.

Conclusion

Do you like golden-brown cutlets the first-time around or do you prefer to get half-cooked ones, only to have to take them back to the kitchen again for a second round of cooking? I think the answer is obvious. TDD is something you should include as part of your development process.