No more excuses

Take the time back with your family. Stop giving up your nights and weekends fighting fires that could have been prevented.

Have you had déjà vu while fixing a bug because you know you have fixed it before? I am confident it is a result of not writing a unit test the first time you fixed it. The larger the code base, the more difficult it becomes to understand the dependencies of the code. Fixing one bug can very well break code somewhere else. Unless that code is covered by unit tests the mistake will go undetected.

Not sure where to begin? Start with your next bug. Before you fix it write a unit test to duplicate it. This will be the start of a safety net, there to protect you from errors before they become bugs. This battery of unit tests will allow you to refactor with confidence because the tests will ensure your code functions as expected.

Teams always tell me they are never given time to write unit tests.

You never have time to write unit tests because you never take time to write unit tests. What I mean by this is you are too busy fixing bugs from production because you never wrote unit tests.

The next time you are asked for an estimate, make sure you add time to write unit tests. Do not explain your estimation. Stop feeling the need to justify doing the right thing. Stop asking for permission. If you do not stop the bleeding, you will forever be waiting for the time to write unit tests.

The time you think you are saving by not writing unit tests is exceeded by the amount of time spent fixing a bug in production. If you do not believe me, start a timer the next time you are fighting a bug in production. Measure the amount of time it takes to diagnose and fix the issue. Then measure the amount of time it takes to repair your reputation. Track the time you spend after hours playing catch up to try and deliver the items you committed to deliver that sprint. Do yourself a favor and write a unit test before you fix this bug. Feel free to subtract that time from the total and see which is smaller.

I am certain your managers think you are writing unit tests, so just do it.

Comments (1) -

  • Agree 100%. One of my worst experiences was working on an existing code base that had 0 unit tests. Couple that with the fact that our team was made up entirely of new hires with very little support, and it seemed like almost every commit introduced a regression. And the deja vu thing happened A LOT. Now I'm a firm believer in unit tests and tdd (where it makes sense). Not only can it help with refactoring and preventing regressions, but writing testable code is an exercise that almost always leads to better quality code - loosely coupled/highly cohesive, better at handling change, usually following SOLID principals. All of that leads to code that is easier to maintain, which saves time in the long run.

Add comment