By Adrien Fortuné, developer in the Carrier Management team, part of the Supply Chain at vpTech.

When developing an application with Test Driven Development paradigms, you can take all the time you have and make all possible efforts to test all cases, you miss things and issues happen.

When a bug happens in production, the first thing to assure is to know where the problem happens.

To do this, the first thing is to find a way to reproduce the bug, for example, which input produces the error.

One tool you can use to reproduce a production issue is to write a unit test and run it on your own computer.

Example :

You got a Null Exception that crashes your application.

You write this test to assure that the problem comes to MyAwesomeFunction()

The first time, you run the test, it fails.

Once you know exactly where the bug is in your code, you can easily fix it.

After the fix is done, re-running your test will assure you that you fix, at least, this issue.

With these good practices, you have also facilitated the work of the person who will review your code. This is one of many advantages of TDD in general but really easy to see in bug fixes : the context is clear and changes make direct sense.

Another interesting thing about having this patch test on your code base is that you create documentation for edge cases. This will help newcomers to understand your code and to start developing in your solution.

By using TDD in daily production maintenance, you can fix a bug and deploy a patch within minutes. It’s the only way to have a continuous delivery process with the maximum of stability.

Of course, this approach does not prevent you from monitoring your application when you release a new version, you have to check that you don’t break other things.

You’ll see that the more you accept the TDD way of life, the more your software will be stable and the more you will be confident to push new features in production faster and faster.