I am currently having a discussion with my team about automation test code.

We have a repository that has develop branch and e2e_test branch (automation code). And they are two different projects. For automation, we test against the URL of the app, e.g Dev URL and Stage URL.

Thing is, developers keep merging the develop branch into e2e_test branch, which makes no sense to me, because automation code and SUT or product code are different things. I tried to explain to them, but they argued that when they developed new feature, than e2e_test branch must be updated with new code too. But once again, I told them that but they are too different projects, different code.

And because of this merging, we have a lot of conflict between develop branch and e2e_test branch, which shouldn't have in the first place, because they are different.

Please correct me if I am wrong. And if it is really not necessary to merge develop branch into automation branch, could someone give me some link, or articles, etc. as a proof so that I can convince my team.

Thanks a lot.

  • Do the answers to sqa.stackexchange.com/questions/8088/… help? I would call this a duplicate of that question because it is considering the general case of where test automation code should reside with respect to application code.
    – Kate Paulk
    Commented Feb 21, 2017 at 12:41

3 Answers 3


It sounds like the following scenario:

There are two distinct sections of code - application code and test code. The code is separate and distinct, application vs testing, but there is one key point that joins them:

The test code is running against the application code

So you develop a test suite in the same general code base as the application because of the following factors:

  • When the application is changed it may (even should) break tests and you want to know about that when changing the application.
  • When new functionality is added you need automated tests for it
  • When functionality is removed you need to update the automated tests.

Basically doing these things separately is a hallmark of a waterfall process and that may be what you are expecting. Your colleagues on the other hand may be working on an Agile process and thus see application and test code being written hand-in-hand.

  • You are right that, the test code is running against the application code. In our situations, e2e Tests are running regression tests (UI and functional) for web application. When there is a new build with new features or etc., CI runs all unit tests, then we have a new build for web application, for example, on Dev website.local. And we run e2e tests against it. So, if something is changed or broken, we can know. And for new features, we add new code test for them. With that being said, do we really need to merge develop branch into e2e branch. Thanks for your answer.
    – Ragnarsson
    Commented Feb 21, 2017 at 14:04

Yes, store the test-code as close to the application code as you can.

If you develop with feature branches I would also build (or extend) the end2end tests in the same branch. The feature is not complete if it does not contain the end2end tests.

  • Tests are versioned with the feature, making it easier to support multiple versions.
  • Feature branches can run all tests and can be released separately from other branches (e.g. merged to master after all tests pass)
  • No merge conflicts
  • Forces developers and testers to work together on a feature.
  • It minimizes handovers
  • Developers can maintain/fix tests with ease during feature development

I can only come up with pro's for using the same branch. Get rid of your automation branch.

Different environments should be handled by configuration files. The version deployed to an environment will also contain all the tests so no problems here.

developers keep merging the develop branch into e2e_test branch

This is a key software development practise called "continuous integration" explained well in this article. I see no reason why the test automation code should be handled any different.


I totally support your point of view, one of the common scenarios is when you test many projects using the same test code, I usually build a testing framework that might suit the projects that have same functionalities, and use it to test all projects.

I think that you can convince them by the idea that same automation code works with lots of projects, for example you can write login functionality test code once and use it whenever you have a login functionality to test.

Another thing is if you have to merge the project code and test code in one place, this place should be e2e branch not e2e_test branch, because tests can not be done without a project to test but the opposite case is valid.

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.