Applying a relative path to local OR

Hello,

I have a framework in place using svn as the software versioning tool. However, I've only been able to successfully make a shared OR and a function library stored using a relative path. As such, the suite of automated tests that I wish to place under svn versioning do not work on our second test machine because the path of the local ORs, actions, etc. displayed in the solution explorer contain the actual path.

Does anyone have any suggestions or links to information that would describe what files to place under svn control? I'm prettly well experienced with other automated testing tools, but still haven't been able to fully grasp the structures of the actions, solutions and tests to best place the testing objects under source control.

Snapshots are provided for clarity.

Thanks,

Bret

Tags:

Parents
  • Verified Answer

    Hi Bret!

    Utilizing version control together, or within, UFT, is something every UFT-automation engineer has or is struggling with, and the lack of a proper built-in source control functionality might be one of the biggest drawbacks with UFT. On the upside, UFT has during recent releases been extended with better support for SVN and Git where source conrol management has been implemented directly within its IDE, but the end-product is still not top-notch.

    Our company suffered because of this and decided a couple of years ago to separate and move all code and entities created in UFT, outside UFT. This meant that actions were migrated into function libraries and object repositories were stored as standalone XML-files. Then, wIth both entities stored as readable formats (.qfl and .xml) they could easily be put under a separate version control system.

    More importantly, to handle all of this, you need to build a framework on top to manage the connectivity between function libraries, between function libraries and object repositories, and most importantly the integration between the external entities placed under version control and UFT.

    The bottom line: Evaluate the design of your test automation and have a second thought into if Actions really are the best way to go. Consider other alternatives and rethink which entities you need and do not need from UFT.

    With the best of luck and do not hesitate if you have any additional questions!

Reply
  • Verified Answer

    Hi Bret!

    Utilizing version control together, or within, UFT, is something every UFT-automation engineer has or is struggling with, and the lack of a proper built-in source control functionality might be one of the biggest drawbacks with UFT. On the upside, UFT has during recent releases been extended with better support for SVN and Git where source conrol management has been implemented directly within its IDE, but the end-product is still not top-notch.

    Our company suffered because of this and decided a couple of years ago to separate and move all code and entities created in UFT, outside UFT. This meant that actions were migrated into function libraries and object repositories were stored as standalone XML-files. Then, wIth both entities stored as readable formats (.qfl and .xml) they could easily be put under a separate version control system.

    More importantly, to handle all of this, you need to build a framework on top to manage the connectivity between function libraries, between function libraries and object repositories, and most importantly the integration between the external entities placed under version control and UFT.

    The bottom line: Evaluate the design of your test automation and have a second thought into if Actions really are the best way to go. Consider other alternatives and rethink which entities you need and do not need from UFT.

    With the best of luck and do not hesitate if you have any additional questions!

Children