1

I have two repositories:

  • Backend API (php/laravel). API tests written with codeception

  • Frontend SPA (vue). tests written with jest

I now want to write e2e/acceptance test. The tests should automate UI actions like the regular browser tests, but without mocking the API.

Where would those tests belong to? FE or BE repository?

  • Pro FE: The tests interact with the browser/UI
  • Pro BE: I need to setup and interact with the DB. I.e. I need to have access to the models which are only available in the BE. Otherwise I would need to create them in the FE as well, just for the tests.
  • Third option: only test FE & BE separately and mock API calls in FE tests?

bumped to the homepage by Community 2 days ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • 1
    Are there multiple clients interacting with your BE or just the Vue SPA? Is there CI/CD involved? A brief summary of the pipeline might help guide what to do. I think this question might wind up with an opinion-based answer but a little more info might help describe an advisable thought process. – Cherree Jun 24 at 15:11
  • 1
    You could also 4. have a third repo for e2e, or 5. bring all three things into a single repo. Your choice will be informed by things like alignment of lifecycles, complexity of orchestration, capability of tooling... There's rarely a "right answer". – jonrsharpe Jun 24 at 15:39
  • then maybe list all the ways with their pros and cons in a table as an answer. there is no "right answer" but it might help others to have a list of what should influence the decision on where to have the e2e project located. – globalworming Jun 25 at 8:16
0

How to store code in a repository has many factors.

  • How many people are working on this project?
  • Who is responsible for testing (devs only, devs and qa)?
  • What testing methods are in use: unit tests, integration tests, UI tests?
  • Is there a difference between end-to-end and full stack testing?

Are you the only one working on this project and are responsible for developing and testing it? If so, use whatever strategy that makes sense for you and your own personal workflow.

If you are on team with devs and QA, then a common approach is to keep unit tests with the product source code in the same repository. In your case, front-end unit tests stored with the front-end source code; back-end (API, DB) unit tests stored with the back-end source code. Unit tests are typically in the realm of developer testing.

If you are writing UI end-to-end tests using a tool like Selenium, then it's a good practice to store this in a separate source code repository. This is especially true if you have a separate QA team responsible for writing these tests, which is common. If devs are writing Selenium UI tests and there is no separate QA team, then either the same or separate repositories are fine.

All this to say, it depends on how many people are part of the project and who is responsible for what testing activities. There's not necessarily a "right" answer here, but there are common approaches.

Keep in mind, end-to-end testing typically refers to UI/front-end level tests from a QA perspective. Once you start adding in API or databases tests, I'd refer to this as full stack testing. Of course, this could just be a difference of semantics.

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.