Always write unit tests from get go

‘Always write unit tests from get go’, this is nothing new. If you are following TDD pattern then it is the default style. But when we develop an application which need to be delivered in a short time frame, if you do not have TDD background and testing is not the first class citizen in the programming tool set, before you know it, product will be delivered with no tests. This is always the case if there is no one bugging you about unit tests. 

Let’s talk about building a brand new application. Most of the time, when we develop a brand new application, our application will be very simple compared to what we end up with in three or four years down the road. Most of the time, our initial applications are very simple, which does nothing but bring data from back end and display it in the front end. Nothing much to it. When you have four or five line methods, why would you want to write unit test for it? It is a very bad assumption. You might start with this four line and as the application start growing these four lines might end up becoming twenty to forty lines (of course you might end up re factoring), you increased the complexity 10 fold. Now try to write unit tests and you will be stuck. There might some dependency that need to be removed and need to re factor the code so that we could even start unit testing. Now, unit testing becomes an explicit task which is going to consume time and effort. If you would have written the unit tests as part of initial development then as we add more code to it, our tests will also evolve and when we get to this twenty or forty line of code, there will be plenty of supporting unit tests for it. When someone is trying to modify this forty line method, it has good unit test to back them up so that they know they are not breaking any existing code.

One of the very important benefit of the unit testing which most of the people forget is that it can show you your design flaws very early on. If you are not following SOLID pattern then writing testing is little difficult. We always need to develop application in a loosely coupled model. All the dependencies should be injected into the code, which lends itself to a very maintainable software. If you were writing unit tests early on and if you were stuck on a place where you cannot do unit test, then you have a hard dependency problem or breaking one of the SOLID pattern. Since this problem identified early on, we can change the design to make it testable, we also reduced the complexity during the course of re-factoring. This is a great benefit of adding unit tests in the green field development. Write unit test for any and all the public methods, someone will thank you when they have to add a new feature to the same code after four years.

I hear people say, ‘I will come back and re factor the code and add unit tests’. Trust me when I say this, you are not coming back to re factor, you will have some other better things to do and never will have time to do it. Even if you were to come back to the code, how are you going to justify the task that could have been done in the first time itself? So here is a rule of thumb, if you ever say, ‘ I will come back to code to do something’, then you are knowingly adding tech debt to the code. Don’t just say it, do it. Do the re-factoring add unit tests, take extra effort and do it.  If it take some extra time to do it, I will ask you to talk to the managers and tell them the benefit of the re-factoring. If the managers do not understand (I really hope it is not the case), reach out to the technology leaders of your team. They will help you make the case.