Ignoring overlays when recording

Best practices, code snippets for common functionality, examples, and guidelines.
sle118
Posts: 2
Joined: Wed Aug 03, 2016 1:09 pm

Ignoring overlays when recording

Post by sle118 » Wed Aug 03, 2016 1:45 pm

Hi everyone

I have been experimenting with Ranorex for a couple of weeks now as a "back burner" project and doing mostly SAP. While I found a few shortcomings, they can mostly be addressed by restructuring recordings into a logical repository hierarchy. But I've been facing a challenge with the tracking tool, which I hope will be easy to resolve by more experienced users.

During recording of actions performed on an application, and despite my attempts at creating repository items in advance, Ranorex's tracker gets confused by an overlay and only captures mouse clicks which are relative to it instead of capturing actions on repository items.

Here is what spy is tracing the application's controls:
Image

I thought I found a solution by having a folder created in a way that would ignore that overlay, with the path below.

Code: Select all

/form[@class='SunAwtFrame']/?/?/?/.[@type!='OverpaintablePanel$Overlay']
although this works in the tracker, the recorder refuses to use it and creates a new repository item
Image

I understand all of the test scripts could be hand written (and all of them need to be refactored after recording anyways), but the recorder is a fantastic tool when interacting with power users and not being able to use defeats the purpose of its own existence.

So the question is: is there any way to tell the tracker to SKIP a certain control based on certain attributes? in other words, is it possible to filter out the list of controls that the tracker will consider when resolving a control path?

Thank you!

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

Re: Ignoring overlays when recording

Post by krstcs » Wed Aug 03, 2016 8:59 pm

First, welcome!

Second, could you please post a Ranorex Snapshot of the element instead of a screenshot? Screenshots only show what things look like, not the whole structure and all of the attributes available. See this page for information on creating a Ranorex Snapshot: http://www.ranorex.com/support/user-gui ... files.html.

Additionally, please describe in more detail exactly what you are trying to accomplish. Maybe there is a different/easier way to do it that you haven't thought of.

You are usually going to be better off including more information in the XPath, instead of using wildcards ('?').

For example, assuming you want the Container of type 'SplitDockStation$Content', you could use the following:

Code: Select all

/form/container/container/container[@type='SplitDockStation$Content']
If that name will change, then you can change to using a variable and add " and @type!='OverpaintablePanel$Overlay'" to it like this:

Code: Select all

/form/container/container/container[@type=$typeVariable and @type!='OverpaintablePanel$Overlay']
But, again, without seeing the actual structure and knowing exactly which element you are wanting, it will be hard to help more.


Finally, I will say that I don't use the recorder. I used it when I first started for about 3 recordings to learn how Ranorex did things, and then stopped because I found it easier, once I understood how Ranorex does things, to manually add steps and Repository items (but I did .NET development before starting with Ranorex, not that you need that background, but it is better if you can code). It is much faster once you learn how to add things manually than it is to go back and 'fix' the issues that the recorder might introduce. In addition, I find that making the recordings as small as possible will help in re-use and maintenance. Only have each recording do one thing (click a button, enter a username, etc.). There may be more than one action, but if you keep to this principle it will help a lot. It will mean more test recordings, but you can manage that easier than having really large recordings. Also, note that the Test Cases in the Test Suites are basically large for-each loops that loop over each row in your data connector or run once if there is no data connector (or none if there is no data in the connector, which I abuse to make my tests more dynamic :D ). You can add Test Cases to Test Cases to layer/structure your tests in ways that make it easier to maintain and manage.


Above all else, ask questions. There are quite a few users on the forums that have a great deal of time working with Ranorex and are always willing to help.
Shortcuts usually aren't...

sle118
Posts: 2
Joined: Wed Aug 03, 2016 1:09 pm

Re: Ignoring overlays when recording

Post by sle118 » Thu Aug 04, 2016 3:43 pm

@krstcs, thank you for your response. I'm going to digress a bit here as an exchange beyond a simple issue, into "philosophical" matters is always interesting and is likely to broaden our views on test automation.
Problem statement: the tracker does not "see" controls when they are under an empty overlay
I am very familiar with advanced C# coding techniques and I have mostly done hybrid code so far in Ranorex, combining drag/drop repository items and custom functions when needed. For example, working with the SAP system and validating variant configuration values took 5 minutes to run. The best that could be done with drag/drop code (recording would have been a nightmarish experience) was something that resembled this

Code: Select all

Click "find"
Type the name of the characteristic to look for
Click on the search button
Validate that the found value was good
repeat for each value (30+ of them)
The code ran in a little over 5 minutes, making it almost impossible to test for the 2000 or so iterations that this bit will need to test. It would have taken ~7 days of continuous testing for this single script, which was unacceptable. So the following components were built
  • data grabber

    Code: Select all

    Click on grid
    Click on "go to first page"
    Read value in the grid
    Take a picture of the value row 
    Store both in a global variable of type Dictionary<string,customValue>  (where customValue contains the value and the picture)
    Repeat Read until the end of the current page
    Click on Next Page and Repeat Read
    Repeat Next page until last page
    
    data validation

    Code: Select all

    Receive parameter "value name" and "expected value" 
    Retrieve the value from the dictionary
    Validate that the values match
    Mark the <string,customValue> object as "validated"
    un-validated values report

    Code: Select all

     Select Dictionary<string,customValue> object that was not validated
    Report as warning message
    read next until all un-validated values are processed
    
Once these components were built, they were assembled together into a "recording" that is like this

Code: Select all

Call data grabber
Validate that value "A" is "123"
Validate that value "B" is "456"
[... more values to validate]
Report un-validated variables
Adopting this new approach reduced the execution time to ~15 seconds, or around an hour for all the iterations. This approach hides the complexity under user functions and allow easy mapping of values by less "tech savvy" resources and therefore reduce maintenance costs.

Recordings, on the other hand, give you "code" which is often too rough to even start mapping data fields. Consider the following example

Code: Select all

Click on field A
Enter value "1"
Enter "{TAB}"
Enter value "2"
That sequence is too often interpreted by the recorder as

Code: Select all

Click on field A
Enter a value "1{TAB}2"
Other tools I use (which I am not going to name here) actually convert code to the following, making it easier to map data at a later time

Code: Select all

Click on field A
Enter value "1" in field A
Enter value "2" in field B
I'm not saying one is better than the other; Ranorex captures actual key sequences because you might actually be interested in testing how the GUI reacts to various inputs. But if you don't really care about this and all you want to do is capture the results of firm actions like entering data in an app and making sure it works, then Ranorex recordings need some rework/rewrite.

The plan for recordings are to
  • Capture new repository items quickly
    In user sessions, capture steps of a process; no need to take notes
    In user sessions, capture minimum validations that users need; no need to take notes
From these recorded sessions, you get repository items which are likely to be "all over the place" unless you have carefully crafted weights rules to suit your environment. But I think it's faster to take that output as a start and reorganize it with cached root folders under various grouping levels or under global features common throughout a given app, etc. You also get some draft code that is a reference to the process you are testing and makes it easier to then dispatch the refactoring activities to resources that may not know how the business process/application work.

I hope it make sense, but I am sure this will eventually evolve when more scripts are written.

p.s. I didn't want to post the snapshot because I would have had to heavily edit it to remove some bits to protect intellectual property; I won't go in too much details here. The reason I put up a screenshot is to highlight the hierarchical portion of the snapshot, which places an overlay before the other container and contributes to the recording issues I am facing.

p.s.s. Sorry for the long post, and if you've been patient enough to read to this point, then thank you!

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

Re: Ignoring overlays when recording

Post by krstcs » Thu Aug 04, 2016 4:18 pm

No worries! I never know on these forums who has what experience, so I tend to start at the lowest level to make sure we get a good base-line.

Unfortunately, without seeing the snapshot it will be difficult to really understand what you are seeing and form potential solutions that would be more than just generic "try this" type things. But, I do understand the need to keep things private. One thing you could do is email the Ranorex team at [email protected]. They can sign NDAs if needed and will be glad to help. If that is still not possible, would you be able to have a dev create a similar SAP app without the proprietary bits that demonstrates the overlay issue and post the snapshot of it instead?

I've also worked with some of the "big" names in automation, and, as I said in my original, Ranorex takes some getting used to, but I think it's much better than the others. But, just my opinion...

And, I did read it all! :D
Shortcuts usually aren't...