4

I am using Cypress for my e2e tests and k6 for my performance tests. They are both in Javascript and access the same config json files (I use this for my environment variables).

The folder structure looks like this:

|- config
|- cypress
|- k6
|- cypress.json
|- package-lock.json
|- package.json

I am fine with this currently as I only need to maintain one repository. My npm packages sit on same repo as well which is good if both tools would like to use them. I also have one yaml file which I use for my CI pipeline and can be interchanged via scripts placed under the package.json file.

However, I am having doubts if this is the right approach if we scale further. It might become this big monolith where everyone needs to access the same repo and multiple QA's doing multiple PR's.

Our organization relies heavily on the regression test suite, hence, we separated our e2e test from our codebase (devs still think of unit tests as an afterthought - slowly trying to change that but we're not there yet).

Improve this question

1 Answer 1

Reset to default
2

The answer is, it depends. It would be helpful to know more information on the makeup of your team/organization. How many people do dev work, QA work, DevOps work? How many team members and the setup of the team can make a difference to solutions.

Option 1: You can keep your e2e and performance tests in the same repository as your application if you're the only one working on the app or it's a very small team. But like you mention, this can create issues with scale over time.

One example of this I've seen is that if QA normally writes the automated e2e tests, then developers "require" they approve all pull requests into the main branch, even if it's test related. This can slow down testing efforts if those developers don't prioritize testing work to the same level of developer work. (This is based on personal experience.)

Option 2: You can separate your e2e and performance tests into their own repositories. This gives you better scale over time. If there are multiple QA and DevOps doing the e2e (QA) and performance (DevOps) tests, then it's easier for those groups to own their own repositories.

Option 2 is the standard setup I've seen how most teams work. It takes into consideration each roles impact on the SDLC and the application. It takes into consideration "separation of concerns." Teams can move faster. It makes the developers a "user" of the e2e and performance test, not a creator or maintainer of those tests.

Improve this answer
2
  • 1
    Yes, Ive read articles on how it depends on the structure of teams and would vary organisation by organisation. Base on our current situation, I think I would go with Option 2 as you have suggested as its easier to maintain two separate config files than maintaining a whole big monolith repository. Thanks!
    – ebanster
    Commented Jan 20, 2021 at 9:18
  • You're welcome. If you could mark this as the accepted answer, that would be great!
    – Lee Jensen
    Commented Jan 20, 2021 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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