Good practices for maintaining scripts into the future

Ask general questions here.
ancleg
Posts: 11
Joined: Thu Dec 20, 2018 4:03 pm

Good practices for maintaining scripts into the future

Post by ancleg » Wed Feb 06, 2019 10:17 pm

Trying to do a bit of planning for the future here.

Our problem: We have scripts that run now, but say version 10 comes out of our software and we need to change the script. We would like our "old" script to keep running in-case we need to redo anything, so some thoughts we've had:
  1. Copy the project (on disk, not using Save As) and rename it (carefully) to include the new version
  2. Use Smart Folders to break up anything that needs a new version. Say Logging In stays the same, but Logging Out changes. We would make Smart Folders for each version of Logging Out and use Run Configurations to say which version to run.
There's pros and cons to each, and other methods as well I'm sure. I'm very conflicted over which method seems best.

Also there's the problem of usercode Libraries that point to old stuff. Just make a new version of usercode Libraries and point the new version scripts at the new usercode Library?

User avatar
Stub
Posts: 240
Joined: Fri Jul 15, 2016 1:35 pm

Re: Good practices for maintaining scripts into the future

Post by Stub » Thu Feb 07, 2019 9:27 am

What we do here is associate the Ranorex testing code with a particular version of the software under source control. We branch at each new version. And then we basically just leave that old branch in maintenance mode, with any edits being merged where appropriate.

The software then proceeds ahead with further changes for the next version and the Ranorex test code evolves to match. That way we can continue to run the old Ranorex test code on the older versions without having to worry about conditionalising the Ranorex test code to cope with multiple different versions of the software. It works for us so far and keeps the Ranorex test code clean, though we've only been using Ranorex for just over a couple of years.

That said I have recently started using Ranorex smart folders to separate out behaviour because we're working on a feature in a branch we plan to merge in shortly. Since there is some divergent behaviour I've partitioned the differences in conditionalised smart folders which I'll drop when we merge. This just helps me ensure we haven't broken anything in the feature branch compared to the main branch, something which has been fantastically useful for me.