User Tag List

Results 1 to 2 of 2
  1. #1
    Advanced Member tarun kumar's Avatar
    Join Date
    Jan 2007
    Bangalore, India
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)

    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?

  2. #2
    SQA Knight
    Join Date
    May 2006
    Playa Del Rey, California, United States
    Post Thanks / Like
    17 Post(s)
    1 Thread(s)

    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.

    David Lai
    SDET / Consultant
    LinkedIn profile



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 03:49 PM.

Copyright BetaSoft Inc.