So you’ve acknowledged you’re stuck with a piece of legacy code. One of the things that might be missing are automated tests. Is it possible to add tests to this application retroactively? That is, write tests for features that have already been implemented? Short answer: yes! Long answer: read on…
The Situation
There is a Chinese proverb: “The best moment to plant a tree was 20 years ago. The second best moment is now.” Keep that in mind as we look at the current situation.
Let’s say your application has little to no automated tests. I’ve already explained why you need automated tests, and which kind you can use. But many applications lack a decent test suite.
And actually, that’s OK. There are all kinds of reasons that could have led to this situation:
- lack of experienced developers
- experimental nature of the application
- the need for extremely fast development or time-to-market
But that was then, and this is now. We can ponder about how we should have written tests, but the fact remains that we didn’t. However, there usually aren’t many reason not to start writing tests now.
So we have an application lacking automated tests, and we want to change that. How do we get started?
Gage Interest
You as a manager might be convinced you need automated tests, not all developers are. And maybe your developers are of that opinion. But you might be lucky and have developers that are very willing to start writing tests. Chances are that it’s somewhere in the middle: some are enthusiastic, others are against the idea and even others might not care one way or the other.
Here’s where your knowledge of the team comes into play. Depending on the team dynamics, it might be possible that a few enthusiastic leaders can convince the skeptics. If, on the other hand, the natural leader of the group is a skeptic (or indifferent), he or she could pull the entire team away from the idea.
Knowing the interest and team dynamics will be important for later steps.
Educate If Necessary
If the team or some team members lack experience with automated tests, they will need to learn. This can come from colleagues with the correct knowledge, courses, or external help.
If you need help deciding here, feel free to contact me to exchange some ideas.
Force The Team?
What if there is no enthusiasm at all for writing automated tests? Should you just force the team to do so?
If all else fails, maybe. But understand the consequences. People will either leave, become very unhappy or trick the system (writing tests that don’t really test a lot). Neither is a good outcome for your organization.
To make matters worse, this refusal would be a symptom of a HR problem. Why were these types of developers even hired? If you can’t evolve as a developer, especially by adopting an industry-standard practice, you’re not the right person for the job.
Start Small, Take Time
Let the team start small. It isn’t necessary to have a complete range of automated tests immediately. Some parts of the application will even be nearly impossible to test automatically, because of the way it was written. Adding automated tests to existing code isn’t easy!
But trust your team to find the places where they can create value without investing too much effort. Over time, they will gain experience and get to the harder parts.
What Not To Do
I’ve seen (parts of) organizations focus on the wrong things when starting with automated tests.
Don’t Focus On Test Coverage
Test coverage is one of them. Test coverage is a number indicating what percentage of the code is covered by tests. It doesn’t really say much about the quality of your tests, but it can give an indication of how many work you still have in front of you.
However, requesting 100% test coverage of your teams is usually a silly idea. Or any other arbitrary number. Developers will have to write tests for trivial pieces of code, which is a waste of time and destroys morale.
I’d recommend not to look at test coverage at all when starting. Over time, when your developers are writing tests as a habit, then you can start looking at this metric. It can then help you identify areas with low test coverage. Or, given the correct tools, you could notice areas with diminishing test coverage over time.
Don’t forget to involve the team in this.
Don’t Dedicate Resources To Writing Tests
Something else I’ve seen before is someone coming up with the idea to have some resources dedicated to writing tests. This can be a fixed time slot (e.g. one day a week) or a fixed person (often a junior developer, sadly).
Please don’t do this. It’s not a fun thing to do and while they’re writing tests, your team isn’t adding business value. Technical value yes, but not business value. Tests are best when written together with the actual feature (or bugfix). So build out your test suite together with your application.
Also, don’t let a developer write nothing but tests. It destroys morale. I’ve been in this situation, and I left the company a few months later.
It Takes Time
The best way to build up an extensive test suite, is to have the team start writing tests for every new piece of code they write. This teaches them the habit of writing tests along with their code, proving their code works.
Over time, the test suite will increase it’s test coverage and really prove it’s value.