Ranorex solution best practices

Ask general questions here.
Posts: 11
Joined: Tue Jul 08, 2014 1:54 pm

Ranorex solution best practices

Post by mirih87 » Wed Jul 16, 2014 11:38 am

I am a developer working to create program architecture for running automated tests (Ranorex) for a small startup company.
The company develops a file security system which involves desktop applications, web products (server & client) and mobile.
The tests I'm planning to create will include different operating systems (32/64 bit)that may or may not have a different UI as well as different versions of applications like office, pdf etc…
How many repository objects are recommended? Should I use separated repository elements per environment (web /desktop apps etc.) or should I use only one repository object per project or other options?
Does anyone have some advice on best practices on how to build my solution? Should I use different solutions? different projects? folders?
What are the use cases for using these different design and separations in Ranorex?
How do you run your projects – per application or per environment? I'm planning to use Ranorex for both sanity tests and for running specific small scale tests:
• Running multiple scenarios on a specific machine
• Running a specific scenario on a specific machine
• Running a specific scenario on multiple machines
• Running multiple scenarios on a multiple machines

After we will finish the initial building blocks for testing our agent solution, we will move forward to test our mobile product. The tests will include different browser tests and versions. Do we need to consider these tests for our decision about the program architecture (solutions) at this initial stage?

Thanks in advance

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

Re: Ranorex solution best practices

Post by krstcs » Wed Jul 16, 2014 3:29 pm

Short answer (and the unhelpful one... :D ): It depends on what you're testing, and it's really up to you.

The more involved answer: It depends on what you're testing, and it's really up to you, but... ;)

1. Keep your modules very small. One module, one action (or more correctly, one atomic action set). For example, if you need to click the OK button, the module could be named "Click_OKButton" and would have only one (1) action, Mouse->Click->Left->OKButton. If you need to enter a username or password, you could name the module "Enter_UserName" and it would have a few actions:
1. Click the field.
2. 'Ctrl-A' on the field.
3. 'Del' on the field.
4. Key sequence on the field with the username variable.
5. Validate the field now contains the username.

This is really one action, just with a few steps.

The key is that you want to be able to drag and drop your modules into a test case and use the test case ordering to determine the logical flow. This also allows you to reuse the modules as much as possible.

As an aside here, you will want to do less record and playback and more manual module creation with this system, but it works better in the long run.

2. Different platforms should probably be in different test solutions. We have a point of sale system, ecommerce system, custom solution design system, etc. Each has their own solution. They used different methods of providing objects to the user, so they are in different solutions (Java vs HTML). I have one library solution for anything that multiple projects will be using (data manipulation is here for example).

3. The repository can have as much or as little as you think it needs. I would suggest that each separate solution have it's own, as long as it makes sense. If two solutions are on the same platform (2 Win32 apps, for example), but have different business logic, you can use one repository in both places. But, you could also just make several projects inside the solution and just have the projects use the same repository.

4. I set up my solutions a bit differently than many. The first project is always called <Solution>_CORE, so for my web project, the solution is "TCS_WEB" and the first project is "TCS_WEB_CORE". This CORE project contains ALL modules and the repository (the exception is any module that would only be used in one project should be in that project). The CORE project does not get run as a test, but it does have a test suite which is used for testing modules and data sets. All of the actual tests have their own project in the solution. I just drag modules from CORE into the different suites and Ranorex automatically updates the project dependencies.
**There is a trick to this, when you create the new project, you must select the "Ranorex C# Test Suite" (under the root C# folder in the New Project dialog) project, instead of the default "Ranorex Test Suite Module Library" project type.

For example, my web project looks like this:


5. Use Jenkins. A lot. If set up correctly, it will do all of the test management and reporting that you are wanting. I have my tests setup so that Jenkins' configuration can be sent to the tests through the command line, so they can will run on the correct browser and site, with the correct data.

6. As far as organizing the projects, since I use only one project for all the modules, I use folders a lot. Basically every page that my test hits will have a different folder for modules that are specific to that page and some have sub-folders for different things. Generic modules (like "Click_OKButton" or "Enter_ZIPCode") that can be used in multiple places sit in the core of the project so they are easier to see.

7. On web projects specifically (and some other projects) where you need to wait on things to happen, you should create a module specifically for waiting on pages to load. Mine is "_WAIT_FOR_PAGE_RELOAD". Notice the "_" underscore at the start, and the all-upper name. This makes it easy to find (always at the top of the module lists) and to distinguish from other modules. This is the ONE and ONLY place that you will need to make timing changes for page loads. This module should be placed after any other module that causes a page load. You can then use it to keep your timing controlled. If you tried to do this in every module that reloaded the page, you would have to change every one of them each time you needed to adjust the timing. It will mean that you have to put it EVERYWHERE, but that is much easier than remembering every place you need to adjust timing. In conjunction with this, I have 2 repo objects for my web site's /dom. One is for state!='complete', and has nothing under it. The other is for state='complete' and has all the other child objects. I can then wait for the complete one to exist in the WAIT module. It would look like:

Code: Select all

TCSWEB_Complete -> /dom[@domain=$domain and @state='complete']
--Body -> /body
TCSWEB_Loading  -> /dom[@domain=$domain and @state!='complete']
Action table:

Code: Select all

1. Delay -> 500ms  (this allows the system to start processing the page reload before Ranorex starts the rest of the module)
2. Wait for not exist -> 30s -> TCSWEB_Loading
3. Delay -> 1s (some pages will show complete and then start loading another set of scripts)
4. Wait for not exist -> 10s -> TCSWEB_Loading
5. Delay -> 1s (might need to do it 3 times, but you might be able to leave this off)
6. Wait for not exist -> 10s -> TCSWEB_Loading
7. Delay -> 500ms
8. Validate -> Exists -> TCSWEB_Complete (if it hasn't loaded by now something is wrong, so we want to fail here so we know where to start looking)
OK, so I think I have overloaded you enough... :D And I can't remember anything else right now, but ask away if you have questions.
Shortcuts usually aren't...

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

Re: Ranorex solution best practices

Post by krstcs » Wed Jul 16, 2014 3:32 pm

Oh, missed the mobile question. I don't do mobile, but it should be managed/configured the same way.

The objects in the repository will be different, and the business logic will probably be different, so it might need a different project.

Also, you can't test mobile web on Safari, Chrome or Firefox, only on the Ranorex created RxBrowser. Due to the limitations/security of mobile, Ranorex needs to inject code into different places in order to automate the apps, so any code that you don't own, you probably won't be able to instrument.
Shortcuts usually aren't...

Posts: 11
Joined: Tue Jul 08, 2014 1:54 pm

Re: Ranorex solution best practices

Post by mirih87 » Sun Jul 20, 2014 12:14 pm

Thank you for your answer :)