Why do we have to code to tests?

Let me start this off by explaining “code to tests”. Tests are a set of conditions or variables under which we can determine if a system satisfies requirements, when they are given to the system. So “code to tests” refers to an approach where we start coding to the test cases that are formed from the requirements, instead of the requirements directly. We write code, not for the solution, but for them to pass the test cases we created.

Does this remind you of TETRIS (old arcade game) ?

Now this looks like Mass Destruction (the tank game), right ?

Battleship ???

Though the images somewhat resemble those games, in this context, they are different formations during Conway’s Game of Life. It is a zero player game, meaning that its evolution is determined by its initial state, requiring no further input. One creates an initial configuration of the game and observes how they evolve when the game is started. The evolution depends on certain rules.

So now, why am I talking about the game?

I happened to attend a Coderetreat session conducted by Venkat S. Dr. Venkat Subramaniam is founder of Agile Developer, Inc., creator of agilelearner.com, and is a member of faculty at the University of Houston. Venkat helps developers through various sessions by sharing thoughts about sustainable agile practices. By definition, Coderetreats are long, intensive sessions focusing on principles of software development and design. It can focus on various aspects like modularity, extensibility, etc.

To kick start the session, the above images were projected on screen and people were assigned the task of coming up with a solution for this. Once I got to know the task at hand, being a developer, my initial feeling was like 😋

I started ATTACKING and quickly came up with a solution. I started coding and could finish it well in time. Post that, when we started discussing on different cases and extensions to the same problem, I realized how easy it would have been, if my code was already built using some safety measures, so that it becomes easier to develop new things on top of it. This was when I was introduced to the concept of Test Driven development or TDD, as we will refer it to from now on.

TDD is defined as a software development process which depends on the repetition of very short development cycle. It is a programming technique that requires us to write actual code and automated test code simultaneously. This helps us make sure that we test our code and also enables us to retest our code quickly, since it’s automated. It has two parts:

• Test First Development (TFD) — where we write test cases and then develop code
• Refactor — improve code by cleaning up.

Let’s get into details of how TDD works:

• It is a development process which takes an iterative approach and the cycle time is very less.
• We start the process by writing test cases for the requirements, that are given, even before the actual development (here in our case coding). A test case can basically be as minimal as comparing the output for a given known input. These test cases, being written, have to be extensive, so that they capture scenarios like errors, inputs, outputs, boundary conditions. The main reason for writing test cases before coding is that our mind is not bounded by any functionality that is already present.
• After that, we start with coding and test our code with the cases written and keep developing like this until all the test cases written, actually pass.
• We refactor code as and when we find better ways to write and still be sure that nothing is broken till all test cases pass.
• As all the test cases we write are in the form of code, it is very easy for us to automate these tests and would take minimal time to test our code against the tests.

As far as advantages of TDD are considered:

• All the building blocks of our application are already very well thought through in terms of different cases that might be fed in and the output it gives.
• As it is automated, it is very easy to test changes we make to our application. So you can rapidly develop features on top of your existing code.
• Automated testing is definitely bound to give us more ground than manual testing, as there is very minimal human intervention to test most of the conditions and once a test case is recorded, it stays. Also there is a very high chance that some conditions might be missed in manual testing. One is not stating that manual testing is not required, but doing this along with manual testing would help in making the testing process more effective.

Testing, though important, would be the first thing to be neglected. To make a product high on quality and stability, testing is very important. Investing time before, would certainly help us down the road. It will help us think well and ensure that we are going in the right path of building a product. I would like to thank Venkat for a wonderful session and introducing me to the world of TDD.