Testing against multiple instances of application

Ask general questions here.
wcrockett
Posts: 17
Joined: Thu Aug 13, 2015 9:30 pm
Location: Fresno, CA

Testing against multiple instances of application

Post by wcrockett » Mon Nov 16, 2015 4:47 pm

Hello all,

We have FOUR instances of our application

-Development
-Staging - copy of Production
-Internal Production - more robust than external
-External Production - slimmed down version of internal

From inside our domain, each of these are accessed by simply changing the URL in the web browser. I want to create one test suite that can be used against all four instances as all of the buttons, menu's, and objects are near the same and should be able to be identified using the same scripts (in most places... where it can't, I can create a new test case to accommodate.)

Where I get tripped up is that my repository seems to be only able to identify objects for the repository the tests were created in (in this case, external prod.) How can I use all of the same repository items with out having them be stuck against a single instance of our application? Is it just a matter of changing the 'BASE: /dom[@domain='xxxx.xxxx.com'] to something that utilizes a wild card?

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Testing against multiple instances of application

Post by krstcs » Mon Nov 16, 2015 6:30 pm

You don't need to use wildcards, necessarily, but you should look into data-driven testing. In this case, I would change the path to:
BASE: /dom[@domain=$myDomain]
This will create a repository (repo) variable named myDomain. Any repo element that you use in your test module that is a descendant of BASE will automatically add myDomain as a module variable that will then need to be bound to a data source in your test suite. You can make the domain data a global parameter (which you could then pass in via the command-line) or a part of another data source (CSV file or simple data table, etc.). Bind the variable to the data source and when the data source changes values, the variable will update automatically.

There are several very good screencasts about testing with Ranorex under the Support -> Screencasts menu. Specifically: http://www.ranorex.com/support/screencasts.html#c3896;

Take time to read the User Guide and go through all of the provided training information on the site and it should answer most of your questions.
Shortcuts usually aren't...

wcrockett
Posts: 17
Joined: Thu Aug 13, 2015 9:30 pm
Location: Fresno, CA

Re: Testing against multiple instances of application

Post by wcrockett » Mon Nov 16, 2015 7:03 pm

krstcs wrote:You don't need to use wildcards, necessarily, but you should look into data-driven testing. In this case, I would change the path to:
BASE: /dom[@domain=$myDomain]
This will create a repository (repo) variable named myDomain. Any repo element that you use in your test module that is a descendant of BASE will automatically add myDomain as a module variable that will then need to be bound to a data source in your test suite. You can make the domain data a global parameter (which you could then pass in via the command-line) or a part of another data source (CSV file or simple data table, etc.). Bind the variable to the data source and when the data source changes values, the variable will update automatically.

There are several very good screencasts about testing with Ranorex under the Support -> Screencasts menu. Specifically:

Take time to read the User Guide and go through all of the provided training information on the site and it should answer most of your questions.
Thank you so much. This is very helpful and I will go down this path.

Thank you.

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Testing against multiple instances of application

Post by krstcs » Mon Nov 16, 2015 7:36 pm

Your welcome!

If you have any other questions after looking at the User Guide and screen casts, don't hesitate to post them. There are usually several great users on here that can help, and the Ranorex Support staff is super!

And if you run into an issue that you need a rapid response for, you can shoot an email to [email protected] and they will get back to you pretty quickly. They tend to focus on email more than the forums, and let us users answer forum questions, so email is usually better for urgent needs.
Shortcuts usually aren't...

wcrockett
Posts: 17
Joined: Thu Aug 13, 2015 9:30 pm
Location: Fresno, CA

Re: Testing against multiple instances of application

Post by wcrockett » Mon Nov 16, 2015 7:46 pm

krstcs wrote:Your welcome!

If you have any other questions after looking at the User Guide and screen casts, don't hesitate to post them. There are usually several great users on here that can help, and the Ranorex Support staff is super!

And if you run into an issue that you need a rapid response for, you can shoot an email to support @ranorex.com and they will get back to you pretty quickly. They tend to focus on email more than the forums, and let us users answer forum questions, so email is usually better for urgent needs.
Thank you. One of the main selling points for Ranorex was the user support and the great forums. We are really just now ramping up strong to bring automation into our testing.

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Testing against multiple instances of application

Post by odklizec » Wed Nov 18, 2015 9:37 am

Hi there,

I would like to add another suggestion. I personally don't like using variables at DOM level. As mentioned by Kelly, using variable in DOM element means that you will see this variable in every recording module and you will have to bind it to the data source or parameter.

Another way is to use simple 'or' condition in DOM xpath, so you don't have to use variable at all. So the definition of your DOM element should look like this...

Code: Select all

/dom[@domain='abc.com' or @domain='def.com']
Eventually, you can use regular expression like this:

Code: Select all

/dom[@domain~'(abc|def).com']
Hope this helps? ;)
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

wcrockett
Posts: 17
Joined: Thu Aug 13, 2015 9:30 pm
Location: Fresno, CA

Re: Testing against multiple instances of application

Post by wcrockett » Wed Nov 18, 2015 4:08 pm

odklizec wrote:Hi there,

I would like to add another suggestion. I personally don't like using variables at DOM level. As mentioned by Kelly, using variable in DOM element means that you will see this variable in every recording module and you will have to bind it to the data source or parameter.

Another way is to use simple 'or' condition in DOM xpath, so you don't have to use variable at all. So the definition of your DOM element should look like this...

Code: Select all

/dom[@domain='abc.com' or @domain='def.com']
Eventually, you can use regular expression like this:

Code: Select all

/dom[@domain~'(abc|def).com']
Hope this helps? ;)
That is an interesting approach. I didn't know I could do or statements in an xPath. How I handled it now is with a global variable. On my launch recordings (that launch and navigate to the page) I created a usercode module to direct the browser based on that variable as well. Seems to work well except for the unbound variable that shows up for every recording...

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Testing against multiple instances of application

Post by krstcs » Wed Nov 18, 2015 9:09 pm

The problem with using an OR in the XPath is that you don't get a failure when your site links you to the wrong page.

We have had several issues with a link being incorrectly targeted to a dev server. The OR will not catch something like that, because it will just happily carry on assuming the domain is correct.

And, AutoBind is your friend.
Shortcuts usually aren't...