Disclaimer: this question is not related to - "Test cases in source code"
I am working on a super fast development environment where manual test cases were given no importance (thankfully things are bright on this front after some pushing) and UI automation was considered the "testing".
Automation code base (Selenium tests) has been part of of application code base. So with every application branch having a dedicated project requirement being developed, it also runs a corresponding automation tests being developed by us for that specific branch. Since we are limited number of QA we end up working in multiple branches at times. And at some point in time (no specific time again) build engineer pushes one of the application code base branch to trunk).
Now this is where problems arise -
Consider we develop tests in one branch (which means application locators, some common utilities, some tests) and this branch is not yet gone to trunk, now we begin to work on new application branch and we need part of code which we developed in other branch. We are at a fix now...
Since merges are not so often, when ever a branch is merged to trunk it eventually results in more conflicts for automation code which could be reduced if merges were more often. And we can not demand merge to trunk for sake of automation code base. There should be good enough application source code also working in branch before it could move to trunk.
So I suggested to take automation code away from application directory. And to keep track of application branches we could have corresponding branches in QA automation project. i.e. application branches feature1, feature2 etc will have corresponding branches feature1, feature2 etc in automation project.
Doing so will allow QA (which means us) to merge to our own trunk as and when we want, and removing current dependency of when automation code goes to application trunk.
The only hurdle which I see at this point is keeping QA automation trunk code in sync with application code trunk so that it could be used to test project code base trunk. But when we merge more often to QA then automation trunk would have tests for some features which may not yet be available in application trunk. So then -
Should we be maintaining a different branch in automation code base which corresponds to application source code trunk. And doing so we could still continue to merge to automation trunk when ever want, or
Have I got it completely wrong and there are better solutions?