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?

  • 1
    That second Con is a lot bigger than the other bullets.
    – Telastyn
    Nov 23 '18 at 19:40
  • Downvoters, can you please read the tooltip of the downvote button before you press it and leave a comment why you think one of those points applies to this questions? Note the downvote button is not for saying "I disagree".
    – Doc Brown
    Nov 23 '18 at 22:19
  • Jack, do you mean "integration tests for testing the interaction of those multiple products among each other"? Or individual integration tests?
    – Doc Brown
    Nov 23 '18 at 22:52
  • @DocBrown In this case, both, all non-unit tests that require the service to be actually running.
    – Dragan R.
    Nov 26 '18 at 14:52

No. If my product code was in separate repos I would never ever make my tests a monorepo. Tests live the code. If you want to have a shared test framework, then make it a (internal) product and give it a repo.

As I mentioned in the comments, your second con is a big con. You’re also missing the usual monorepo cons (harder to find things, slower source control operations, easier to couple disparate things, etc.). And your fifth Pro has the associated Con that it becomes really easy to accidentally run all of the tests. And having separate test/product repos harms refactoring, code reviews, and testing culture in general because you can’t commit code and tests in one changeset.

Don’t overthink it. If your company monorepos then tests go in the repo. If your company multirepos then tests go with the stuff they test and common testing stuff becomes its own repos.

  • How would you manage config files in this case? Using Node.js/Typescript as an example, would you duplicate/extend all existing files used by tests (tsconfig, tslint, selenium webdriver, api, jest config, etc.) across all of your repos? Or would you combine the test dependencies into the dev dependencies? Would these test dependencies also be copy pasted across all repos?
    – Dragan R.
    Nov 26 '18 at 14:58
  • @JackT. - I've not done much of anything in Node/TS, but generally, I treat config like code (since it can break things just as much as code). DRY as appropriate, put sensitive things into a controlled location (connection strings, passwords, crypto keys, etc). In monorepo land that means single reference, in multirepo it's a package (usually either your build system since it does the per-environment config replacements, or your config service if you manage things that way).
    – Telastyn
    Nov 26 '18 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.