🔗 Improving unit test run time in a Laravel modular monolith

I recently started a new job and was given my first exposure to a modular monolith. On the surface, they have a lot to love: all aspects of your app in one repo, one set of dependencies to keep updated, reduced code duplication, and allowing multiple engineering teams to work in in their own isolated sections of the code are first that spring to mind. Modular monoliths of course present some challenges, and the one that kind of struck me by surprise was test suite run time.

In previous projects, test suites usually took at most two minutes to run locally. Parallelization obviously helps a great deal, but it is not a silver bullet. I have spent a great deal of my focus on writing tests that don’t execute extraneous database queries:

• don’t build more than you need
• leverage bulk inserts versus many inserts in a loop
• be mindful of model events that may trigger database queries
• test a single unit of code when possible
• leverage Factory::make() if writing to the database isn’t strictly necessary

These are helpful guidelines, but an unfamiliar codebase with over 19,000 tests is not something that can be optimized quickly, if those opportunities even exist.