Why use test repositories?
The purpose of test repositories is basically to provide a structured storage for all test artefacts from a project. Each type of them is stored in a separate directory. It should prevent a team’s test cases from loss, non-existence, or duplication, and should let them reuse previous testing resources.
Test repositories also allow versioning of test cases and enable numerous testers to work on the same test project without disturbing each other.
Mono repositories vs. multiple repositories
- Monorepo approach: Monorepos are used by one big group of all software testers in an organization. They contain all kinds of test artefacts. Usually, due to less or no clean-ups in them, they even contain legacy data for multiple years.
- Multi-repo approach: This term describes multiple, smaller test repositories that are assigned to several smaller agile teams. These repositories contain only the test artefacts of each respective functionality or agile team. Its test artefacts are usually, thanks to regular regression testing, always up-to-date.
Sometimes, in order to achieve the main characteristics of agility (speed, simplicity, and independence), organizations need to break down their mono repositories into smaller, multiple ones that are based on features or agile team(s).
Let’s dive deeper into both approaches for further analyzation!
Mono test repositories
Working with a mono repository is for many companies a familiar approach and therefore the only one they consider. But this usually only functions well if the repository is not growing exponentially.
Monorepos keep everything a project needs in one place, which (as long as your repo’s size stays the same) gives your teams a good overview of what they already have and what is still missing. All projects have access to the repository and they can all together pursue their testing without blocking each other. This includes E2E testing, since monorepos keep all test artefacts, containing all components of an E2E flow, in one place.
However, in reality, most projects grow over time and so do their test repositories. This is where monorepos reveal drawbacks.
As mentioned earlier, in the monorepo approach, all software testers use one and the same repository for their work. With every update or new feature, the teams will add new test assets in the repository. This means that over time, it will get bigger and bigger, which leads to it becoming also slower and slower. Soon, your repo turns into one big and slow monolith.
Unfortunately, a slow monolithic system usually leads to less regression testing, due to time shortage. This, in turn, results in test cases getting outdated on the one hand, also leaving your teams with higher infrastructure maintenance efforts. On the other hand, a big, slow test repo may, in combination with the waterfall methodology, where testing is generally executed at the end of a development life cycle, lead to needed maintenance efforts due to outdated test cases being detected too late.
Along with that, there is a chance that software testers may be asked to prepare test cases for areas they have less expertise in. After all, the mono repo approach does not distinguish between different teams. Therefore, your testers might also be busy gathering the required informations.
So, in general, such big repos limit your ability to test continuously and therefore to release new applications and their updates fast. At this point, achieving agility becomes a challenge. We recommend a scale down strategy in order to accomplish agility in your growing project, as explained below.
Multiple test repositories
In case you are familiar with the situation above or you want to prevent it from happening, you may want to consider decomposing your monorepo and working with multi-repos instead.
By splitting the test artefacts into multiple, smaller storage facilities, the risk of a slow system decreases dramatically. Each repository then only contains test artefacts of each respective functionality that is assigned to one team. This results in reducing the chance of overloading the system, which also automatically makes it fast. In that manner, your teams will not have to worry about keeping up the speed in their agile project. As you may have guessed, this whole procedure leads to less overall infrastructure maintenance efforts.
Since this method differentiates between various teams, the chance that testers have to prepare test cases for other, less familiar areas is practically 0. This, again, saves them a lot of time.
Furthermore, regression tests can be performed regularly with multi-repos, which in turn results in all test cases always being up-to-date and defects will be detected in earlier stages.
Moreover, decomposing your huge test repositories does not automatically mean that your teams need to consider changing their test automation tool, as you might expect from such a change. Instead, they can stick to the toolsets they know, which does not only save your teams a good amount of time but also your financial resources.
Therefore, working with decomposed repositories gives you full ability to quickly release new applications and their updates. This is exactly what Agile stands for.
However, the question of how to handle E2E testing in this situation still stays open.
The technical gap for E2E testing and how to close it
In the multi-repo approach, the necessary components of a business flow are split into various separate facilities. This only makes the process complicated. As an outcome, it gets unclear who will be responsible for end-to-end testing and how it will be done.
To counteract, it is essential to include the management of E2E testing in one’s testing strategy. For more information on what to consider, take a look at our last blog post.
Unfortunately, there is no such tool that works on top of all test repos and orchestrates all E2E executions, while keeping the load in teams low enough yet.
But, we have what you need!
If you want to know how to overcome this challenge without having to replace already existing tools and complicating things, be sure not to miss our next post.
