The benefits of having your test in the app repo largely depend on your organization. In mine we have the tests with the code, but it's actually not much of a benefit at all because our app logic is all server-side compiled code and there's nothing to test until you've done a full build, deploy and (painful) warmup. (Cypress is great for warmups by the way.) So having it with the code is actually a hinderance because your pull requests for Cypress changes have to follow all the same audit controls that govern the app code. You can also run into silly issues, like the build excluding the Cypress files. Not to mention that a full build/deploy/warmup is triggered every time you commit your Cypress PRs, which is a bit annoying. About the only benefit to me is the developers seeing and approving my PRs, which hasn't resulted in them being more involved, so ¯\\(°_o)/¯ So I can see the argument both ways. If you have a fancy pants way of testing a PR before some larger deployment then by all means include it with the code. But if you're like me you might actually be better off with the code in its own repo.

this is part of my concern as well -- having to drag the weight of the code repo's setup along with me. our codebase is a monorepo with an array of actions and audits that execute on every build, most of which aren't applicable to cypress. i feel that the "same repo forces developers to be more involved with testing" is... well, it assumes that all collaboration is strictly good and useful. but i'm not sure that bothering a developer every time i want to push changes to tests that don't even affect the work they're doing (especially in a monorepo) is a useful type of collaboration. (perhaps in the same way that not all meetings are useful, and too many meetings causes friction and annoyance for little gain.) and yeah, if the team is already organized in a way that separates devs and qa, artificially forcing them to communicate is just a bandaid over the structural reasons why devs and qa aren't incentivized to collaborate.

Well put, especially this: > if the team is already organized in a way that separates devs and qa, artificially forcing them to communicate is just a bandaid over the structural reasons why devs and qa aren't incentivized to collaborate With the advent of Continuous Integration, Continuous Deployment there seems to be this notion that devs do their own testing, and they do it primarily with automation, and if the tests all pass then the code goes straight to production. This would be a really fun way to operate and I would love to be a part of it. And I'm sure for a lot of new projects this happens effortlessly. But I don't see how it can possibly apply to all projects, and even in the best case any existing project/organization will have to do a lot of restructuring and rearchitecting to make this happen. So the reality is that in many organizations QA remains separate and probably will continue to remain separate. We work closely with the devs, sure, but we have our testing responsibilities that don't change based on anything the devs do. I would love to be put out of a job by true CI/CD because that would imply that the devs have figured out a way to make the app fully tested and bulletproof, automatically, all on their own, which is the dream isn't it?