| || |
Moving test automation code from app source code
<I posted this question in another forum. I am reposting it here to get more diverse answers.>
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?
Re: Moving test automation code from app source code
My personal opinion is it's best to keep the test as close to the code as possible. This allows the test to live and breed with the code it's testing. So I think your current approach of branching automation code with application code is probably the better one. There is one exception, but that generally doesn't apply to web apps, which is supporting backwards compatibility. In that case, a single code base is best as your need to keep a living up to date test setup, and it's better to use inheritance and context switching.
Something you can do to reduce the burden if you haven't done so already is the use a framework to divide up more fragile parts of the tests away from more stable parts of it. You probably heard the concept of layered framework, where you have separate packages for test definitions, data, object recognition, business logic, and UI code. By doing this, you can separate out the more volatile layers like object recognition and business. In the Selenium world, you'll be using Page objects, then defining your test in a separate file, then have a driver that feeds data into your tests.
Another thing to consider is using a DCVS (Distributed Concurrent Versioning Tool) if you haven't done so already. Tools that assume a central model have problems with automatic merges because they only see the before and after and not all the deltas in between. DCVS systems are widely popular in open source development as they facilitate merging of code submitted by complete strangers.