Why you should allow developers to write tests for existing code

Is it possible to add Unit Tests to an existing application and if you do decide to add tests to a project, what benefit will this have to an existing application?

I’ve worked on a few projects where the application has been started, the first few features of the app come to life and before the developers realise the application is nearly delivered to the end user, without any Unit Test coverage.
One of the main reasons for this is when an application is started there is usually a tight deadline, or a push to get something out to the end user within the first sprint and there isn’t time considered for the writing of tests. The unit test theory is that a test should be written before any code is written, but with time pressures writing tests is always something ‘we can do later’.

But can unit tests be added to existing code? And what benefit will this bring?

It is possible to write tests for existing code, it is, in fact, a good practice to go through this process for a number of reasons.

It provides confidence that new changes do not break what is already there

First, it stabilises the codebase of the application, providing confidence that any further changes are not going to break the existing code. Once tests have been written for the existing code, developers know that there is a quick way to check if the new feature they are adding is not breaking what is there already. As they go through developing this new feature having the test runner going in the background running all the tests the developer will see straight away if the change they are making is stopping existing code from working as it did before. They will get a red warning, telling them exactly what is no longer work and why.

It highlights areas to developers where code can be improved

The second reason is when writing tests for existing code developers will notice areas where the code can be improved, optimised. When writing a test you need to know exactly what the code you are testing is doing and how it works. Through this investigation, developers will see ways it can be refactored to make improvements. Once this code has been refactored and improved the test will ensure that any further changes don’t break this improved codebase.

Its a great way to onboard new developers to a team

Another reason that allowing your developers to write tests on existing code is it is an excellent way for new developers to a project really understand how an application works. If for example, you have a large enterprise business application, that has many business rules. It can take a new developer to the team to both understand the business rules, but also understand how the application currently supports these rules. If for their first few weeks on a project they are given the task to write the tests for a certain section of the application, maybe an API the application provides or a set of services that the application uses to process user orders. Through writing tests, the new team member will learn, in depth, how the current application works. They will also be involved in how the application is built, deployed, how the processes the team has for committing code, what rules there are in place for writing code. All this they can do through writing tests without affecting the code of the application.

How can tests be added to your existing project?

If you are a project manager or the business owner of an application and your team have said that the Unit Test coverage for the application needs to be improved. There are some things you can do to help this.

Writing tests should be defined as Sprint stories

You don’t need to stop development on new features just to have your team write all the unit tests for the application. This can still continue, but you need to add time to each sprint (if that’s the method you use) to allow the developers time to write tests for part of the application. When it comes to sprint planning have a few stories for writing tests. Prioritise areas of the application where test coverage is low, maybe focus on areas that are more stable, an existing API for example or the data model which isn’t going to change for a while. Assign these write tests user stories to the newer members of the team, so all they can go through all the development processes the team uses.

Improving test coverage can be a gradual process

The existing application doesn’t need to have 100% code coverage straight away. It’s better to add tests gradually as the project progresses, tests can be bought in for existing code. This does mean there is a risk that changes could break another piece of existing code, but if the tests are being written this risk will get less and less the more coverage your application has.

Allow your developers to write tests

When you are planning some work with the team, a new feature to be added. Allow time in estimates for the developers to write tests. If this time is not in the estimates developers will find that they don’t have enough time to not only write the new feature and write the tests. So the tests will start to be left, this will cause the test coverage to reduce over time and you’ll be back to where you were before, with an application that has a lot of functionality and existing code, that isn’t covered by tests.

Your QA team and clients will thank you

Finally, an application that has a higher test coverage, will have fewer bugs. New features won’t cause new bugs to appear in the existing application.
This makes the QA team happy, for them it means that they can be confident that what is already in the application still works as before. They don’t need to thoroughly test the entire application every time there is a release. They can quickly test the existing application and then focus on testing the new features. Any bugs that crop up should be caught by the developers during the development phase when they have their test runner quietly running along as they write code and then warning them as soon as any issues come up. Instead of the QA team raising a new bug.
Having the QA team raise these minor bugs which could have been caught by unit tests, takes time. It adds delays to the latest release of the code being allowed out to the end user.
So if your end users are waiting for a new feature that will greatly improve their experience of an application and this new feature is delayed due to the release not getting past QA because they have to raise a bug for something that has broken in an existing part of the application. The end user will be disappointed, and a happy end user is what we all want.

Unit test coverage is important, it vastly improves the quality of an application, but if due to time constraints an application has been delivered without a high level of test coverage, it’s not the end of the world. By allowing developers to write tests for the existing code, the coverage will grow over time and the quality of the application can be guaranteed when a new feature is released to your happy users.