Aug 14 2018
The Business Case for Unit Tests

Recently I read this great article on the DZone website called The Business Case for Unit Testing by Erik Dietrich In this article, he sets out six reasons why Unit Tests should be considered as a serious business need and what benefits they bring to a business.

Two of the points Erik makes I feel are extremely important as to why Unit Tests are so a crucial part of an application. One, The Test Suite Reduces Deployment Risks, by having a good set of tests that can be run when the application is about to be deployed. There is less risk that issues will occur during this deployment phase, making the application deployment smoother and getting the application to your users quicker.

How do Unit Tests Reduce Deployment Risks?

As an application is being developed, your development team will continue to write test, this leads to greater test coverage of the application.
When it comes to making a deployment to your users, having this large set of tests, which can be run before each deployment, there is more chance that any bugs that have crept into the application will be found before the application is deployed to the end-user.
Within your release process, you can have all the unit tests be run automatically. If any tests fail, the deployment of the application will be stopped. Then the team can look at what caused the test to fail, and fix this issue.
Having these issues caught before the application is deployed to the end-user, means that they will have confidence in using the application. You also as a business owner can have confidence that your application is being released to your paying customers, with the application being thoroughly tested.

The second great point that Erik made was Tighter Feedback Loop for Time Savings. In this section, Erik makes the point that having Unit Tests improves the feedback loop that developers use to see if errors are appearing in their code.

What is this Feedback Loop?

This feedback loop that Erik mentions is where the developer is given feedback straight away if there is a problem in their code, it’s not doing what it should be doing, the code is not fulfilling the requirements that have been set out in the user story.
For example, if you have an Angular based business application, that has the requirement that when the user clicks on the Login button, the application should open a login panel.
So the developer builds the Login section and adds a Login button that loads the Login section. As part of this, they need to check that the user is not already logged in. Now in their code, they could have a function which clears any current login sessions. This code could have a bug in it where it fails to clear all the logged in sessions. So being a good Angular developer, they write a Unit Test that checks for the list of login sessions, and confirms that this list is 0 when the Login button has been clicked (this confirms that when the user clicks Login, any previous logins have been cleared so they never see someone else account details).
Now 6 months later a new requirement has come in that the Login process needs to write to a database when the login was made so a report can be produced to show user logins. As part of adding this new functionality the clear logins code gets amended and a bug is introduced. It looks like its still working, but the login sessions aren’t being cleared.
Without a Unit Test to check that the functionality of the code still works as expected, this bug could get through to the paying customer, causing major problems.
With the developer using Unit Tests, they would get feedback straight away that the changes they are making to this Login process have caused this new bug. They will fix the issue even before it goes any further.
As Erik says, A unit test suite makes you much more likely to catch errors sooner than later. It does this by tightening the feedback loop. so with a good test suite in place, you’re far less likely to spend disproportionate amounts of time tracking down, reproducing, and fixing issues and the code you’ve built on top of them.
Reducing this time tracking, reproducing and fixing issues, saves money and gets the application out to the customer sooner than later.

Unit Tests are important to a project, especially a long-term business critical application. They have a real benefit to the business and are not something a developer is just ‘wasting’ time with.

The full article by Erik has some really good points and is well worth reading, whether you are a developer or a project manager of a business owner.

Stephen Adams 0 Comments
Aug 8 2018
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.

Stephen Adams 0 Comments