wildcard character in URL proprerties

Friday, November 21, 2014 1:26:42 PM
We're building a common objects list for an application, starting from our IDE, to use the same list for different test . In this way the recorder don't have to learn the object.
Many objects have the field url that ends with ?1234 where the number is the session id. This means that everytime we run again the recorder, the recorder learn a new object and use this new one in the script.
I check the properties for the old and the new one and they differs only in the URL property.
In "play mode" everything works fine, I guess the engine use only the xpath to identify an object, so it's the same have SeS('ok').DoClick(); or SeS('ok1').DoClick(); for the testing purpose. In any case the application set up a new and different session id and use it for the current session (I see that in the browser address bar).
So finally the question: it's possible to use a wildcard character to write the URL properties (i.e http://myapplication.com?* instead  http://myapplication.com?1234) or use something "like" in SQL or a regular expression to prevent duplicate in objects list?
Thanks and regards

1 Replies
Monday, November 24, 2014 2:56:59 PM
re: bllmtt on Friday, November 21, 2014 1:26:42 PM
The described situation is typical and common. We have the following approach to deal with it.

The URL parameter is actually used only once in the test. Once the first web object is recognized Rapise will look at its URL. If browser is not open then new window is created and navigated to the URL specified in the object. If browser is open the URL is compared to currently open URL and then navigated. That is why we don't allow using wildcards: URL might be needed for navigation and should be used properly.

It is common situation that URL changes (due to session-specific parameters).

Say we have 'OK' object with URL: http://myapplication.com?1234
Suppose that we also have several objects further in the test flow (say, 'Vote') also having this URL.

The test looks like:
SeS('OK').DoClick(); // URL is used here. If not match - redirect to URL
SeS('Vote').DoClick(); // URL is ignored, object is looked by XPATH

In this case URL is actually used only in the 1st statement. So we may use the trick on overriding it in the following way:

SeS('OK', {url: 'http://myapplication.com/'} ).DoClick(); // Here we patch initial URL
SeS('Vote').DoClick(); // Here object's URL is ignored.

I.e. the specified approach allows changing object recognition parameter 'URL' when calling the SeS function.

This approach also allows parameterizing the test to work with different sites (i.e. once work with staging1 environment and then work in dev environment) without re-learning objects.

  • Started: Friday, November 21, 2014 1:26:42 PM
  • Last Reply: Monday, November 24, 2014 2:56:59 PM
  • Replies: 1
  • Views: 4952