[Gigachad]

Tests in seperate repo is the worst anti pattern I have seen. It’s extremely common that a change requires a change in tests but it’s impossible to correctly manage this situation if the tests can’t be updated in the same commit/pr.

[cstoner]

The only time "tests in a separate repo" makes sense to me is if they are truly cross-functional end to end tests that exercise several systems.

Those tests should be as small as possible to verify that everything is still wired together correctly.

Everything else should be either unit tests or narrow integration tests between a small handful of components. And as you said, they should live in the repository of the software they test.

[jeroenhd]

I can't think of any project I've worked on where external test suites even make sense. I suppose it would work when you have a very clear spec or compliance document you could write independent tests, or if you're rewriting a system and need the public API to be bug-for-bug compatible with the old one, but other than those niche use cases I wouldn't want to keep those tests external at all.

Even if you do have external tests, you still need internal ones for the surface area your external tests don't check for. Unit tests and such don't make sense at all combined with a separate test repo.

[drothlis]

Think systems integrators and compliance tests. I would imagine that each of the individual systems being "integrated" do have their own unit tests, upstream, in their own repos.

[Gigachad]

In that case you have to release versions with compatibility for both the new and old way. At no point can I ever see it being a good idea to just let tests fail.

[adamwk]

It also makes it impossible to test outside of the public API