Assumption: Each product codebase is in a separate repo. If the product codebase was a mono repo, it would be a no brainer to just put them together.
Assumption: Integration tests in this context would include end-to-end UI-layer tests (e.g. Selenium) and end-to-end API-layer tests (e.g. GraphQL/Rest). Tests requires real running services.
Mono Test Repo Pros:
- Shared test frameworks (applies to both UI and API tests)
Shared test reporting libs
Shared configuration files (e.g. various browser configuration sets for UI tests)
UI setup/teardowns can reuse parts of the API test framework (e.g. a UI test can use a /create endpoint for quicker data setup)
Easy to integrate into CI
git clone monorepo && ./monorepo/run-test.sh --tags=[YourProduct](this is oversimplified, but similar idea)
Easy to get test reports aggregating all your products (or combinations of them), without any external tools (e.g.
./monorepo/run-test.sh --tags=*-- again, also oversimplified)
Easy to add new products. Just create a new product folder, tags, and use dependancy injected context variables in tests (e.g. Browser Clients, API Clients, etc.)
Mono Test Repo Cons:
Decoupled from codebase, no longer lies close to codebase
If built poorly, a change in a shared test framework can affect other products' tests
It sounds like a mess, but there a lot more Pros than Cons. What are some more Cons to this? Would you ever recommend or even consider this approach? Why or why not?