Reading Time: 2 minutes

Testing code is essential for finding bugs before they get into production. Without automated tests it will take longer and longer to debug code as it grows in size and complexity and development will grind to a halt. I am consulting for a company that has not made it a priority to test its code. Thus, one of our early priorities was to write unit tests for their code. This was a big mistake. We should have first done integration and performance testing on a part of the code, and then done unit testing on that part. This could have been done to the code part by part. Why was it a mistake to write unit tests before integration testing? Writing proper unit tests required refactoring the code, and that meant that the client was not confident that we hadn’t degraded the performance of the code or entirely broken it. We created many branches with many unit tests, but we could not merge them with the develop branch, because we had no way to prove to the client and ourselves that our refactoring was an improvement, and as time passes and the code changes the merger becomes more and more difficult. The code in question is the backend API for an application and most of the code dealt with sending SQL queries to a database. Midway through the first sprint we decided to perform tests with H2, an in-memory database. These were not true unit tests. They were integration tests. Unfortunately we would not have been able to reach our goal of 25 % test coverage by the end of the sprint, had we continued with integration testing, so we switched back to unit testing. To prove to our client and ourselves that our refactoring had been beneficial I wrote Postman tests, while the other members of the team focused on unit testing. To create the Postman tests I sent requests to the various APIs using the master branch and copied and pasted the response to the tests. The Postman tests were then run on the refactored code. The time taken for each Postman request using the master branch was measured and the time taken by the request for the refactored code was tested. I also sat down with an employee of the client and went over a set of manual tests, that could be used to confirm that the functionality of the code had not changed. These manual tests will eventually be automated. The client has also requested Gatling tests to ensure that the performance of the code has not degraded and that is one of our priorities.

The moral of the story is that we should have worked with the client more to come up with a testing strategy before starting to test the code.