Should we store automation test code with the application code?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.