Posted on December 28, 2020

This article will take about 3 minutes to read.

Automated tests are an important topic when talking about software quality, and when your team or project starts to grow, new challenges appear. In this article, I’ll cover some aspects/issues of unit tests in big teams and how to fix them.

At scale, there are a few key root causes of issues with unit testing: no standardization or guidelines, duplicated code, flaky tests, no documentation. In my experience, these issues increase following the project growth.

When a project starts to grow fast (e.g. double the size in less than a year) and in a non-structured way (without documentation, guidelines, onboarding) some situations can happen in a sequence:

• New developers tend to write code following undocumented guidelines. For instance: “I looked in our features figured that the pattern was X, so I followed that” or “I asked for help and someone told me to follow this way”. As expected, this situation will happen with unit tests too.
• After some time, these new practices were added through the project, and then, some questions will arise about what is expected (or even “right”). In some cases, these kinds of questions may appear during code review, tech meetings, or just idle talk.
• When the team realizes, the codebase has a bunch of patterns, techniques, approaches, different names for the same concept, duplicated code, etc. Needless to say this will also happen to tests.

Created on autodraw.com/

So, if your team is growing fast, you are recognizing the situations that I described above, and want to avoid the red arrow, consider following my tips about unit testing at scale:

• Define a test stack after understanding the tradeoffs, e.g. “should we use libraries X or Y?”, or “what are the benefits of lib X or Y?”, etc. Most importantly, after the decisions are made, documenting the whys and sharing that document with the entire team, is key.
• Apply a linter to test files. If your production code has a linter, why not have a linter for the tests as well? Code is code, right?
• Create guidelines about naming. “How should I name my Spy/Mock/Dummy file?”, or “What suffix should I use in the property that changes when some method is called?”, or “How should I name my test functions?”. These questions will come up and it’s important to have a document to answer them. If you use code generation within your project, also consider standardizing the name of the generated code whenever possible.