4

I'm currently writing API and UI automated tests for a website. My goal is to plug these tests in the CI workflow (Jenkins is used in this organization). The workflow would be: if there's a new commit on the SUT's repo, then trigger a build of my automated tests.

The question I ask myself is: shall I store these tests in the same repo than the SUT? Does it make a difference?

Please tell me about your experiences...

Thanks in advance.

  • Hi if you are deploying the test scripts to a different test server to execute the steps, then it doesn't matter wer you keep your code. I will go for a separate branch or repo as it will ensure that we don't confuse developers with our commits – PDHide Mar 17 at 5:48
  • 1
    So what happens when you push new test scripts? it will again deploy a new version of the SUT, and I think in most companies a new version is not allowed unless there are changes in SUT. – PDHide Mar 17 at 10:14
2

When to choose different branch or repo

If you are deploying the test scripts to a different test server to execute the steps and is executed completely independent of the source code or minimal dependency. Then it doesn't matter where you keep your code. I would suggest adding the test scripts and the required dependency together and store it under a separate branch or repo as it will ensure that we don't confuse developers with our commits and files.

When to choose, merging to master branch of SUT source code

If test is executed as a build test step in package.json or maven then add it under the same repo and branch as the product getting deployed.

| improve this answer | |
2

This is a great question and one that many organizations face.

I recommend keeping the test code and the application code together because this will, at the highest level, help keep (or perhaps 'force') application and automation developers closer to each other in many other ways.

It would be 'easier' to have the repos separate, however this is a very short-term view and it is a view that promotes each group to focus on their own work only and not consider the other party's contribution as part of the same puzzle.

To make the same repo approach workable, reliable, helpful and less painful to use consider the following practices:

  • Continuous integration
  • No pending tests
  • Full involvement of both groups in planning, grooming and 3 amigos
  • Work on a reliable test suite that can be trusted, e.g. test failure rate less than 0.1%

In the large view, avoid:

  • different repo,
  • differrent location (e.g. offshore),
  • different sprint (e.g. sprint+1)

because they all push devs and testers apart and the point of testing should not be so much a defensive 'does it work / is it broken' for go / no-go decisions, instead testing should be providing immediate and valuable feedback to developers about code that needs to be fixed or improved. Companies that fully master this have moved from deploying every six months to deploying every few minutes. This is what the largest silicon valley companies do now. Netflix, Facebook, etc.

| improve this answer | |
1

It doesn't matter, from a technical perspective. You can point your trigger to any path (test repo).

The important thing is to respect the naming convention, so no one gets confused with it. I once had a developer ask me "Hey why do you have access to SUT-tests folder?" Unknowingly, I created tests inside folder with that name, but the devs would call their unit-tests folder that way.

| improve this answer | |

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.