TDD and CI - An Analogy

More often unit tests are considered to be time consumers, lines of code that add no real value to the core working of the system. Business Requirements have a first class place in the project as well as the "real" code but unit tests do not get such a place as often as they deserve.

Lately in my work I have to do lot of convincing and mentoring developers on TDD & CI and encourage them to write more unit tests. To convince and to justify the need for TDD and more unit tests and CI I came up with this analogy.

In my analogy consider the lines of "real" code that do business logic or UI logic or data access logic as the people in society. As there are good and bad elements of the society so are good and bad code modules and lines of code. As people we tend to take different roles and actions in day to day life. We drive, we go out to eat, we take a walk in park, we shop. So do these lines of code in the system take different contexts. The same method in a DAO or Service class may be used by a Web frontend or by a batch job. Some of the domain objects may be used by the UI in a certain way and persisted in database or other remote stores.

Now lets talk about the business requirements. To keep people behave well and in sanity laws are formed. Some are explicit - such as the driving laws and some are implicit - well, we don't toss burgers in a restaurants, its bad manners. The business requirements for a system are such laws that the code needs to adhere to. The code must satisfy the requirements.

Here is the fun part - In the society we have cops and agents that enforce these laws on the society. What do we have in software applications that enforce these requirements? This is where TDD, CI and even BDD comes in. It enforces that our code behaves well. If a line of code breaks a unit test it means it violated the law (the business requirements) in some way and this line of code must of brought to justice. Without unit tests we can only assume that the lines of code will behave, but what happens when a change in requirement comes up and we change the code without enforcing the new and old laws?

There can be an argument that functional testing is a good way to enforce the requirements. This can be true to a certain extent. The part of this that worries me are two things. One is that functional testing is performed at specific milestones in the project cycle. The lines of code live on after this milestone has passed and often times these lines of code change without anymore functional testing. Will it help if the cops come in a city only once a month and assumes that things are well in the city rest of the days? The second trouble is that it is not guaranteed that functional testing will cover all lines of code. Well good functional tests would at some point cover lines of code but where is the metric?

The point to be taken here is that write unit tests - these are the cops of your code. If some other developer comes and changes these lines of code and unknowingly causes them to be bad elements of the software society the cops (unit tests) will catch em.

Long Time !!!

It has been quite a busy time the last 4 months. My little baby girl was born on Jan 11 and that marks a major milestone in the life. As the sleepless nights settle I would start blogging more.