Looping repeating modules in a test case

Ranorex Studio, Spy, Recorder, and Driver.
MarkW
Posts: 6
Joined: Tue Feb 09, 2016 6:03 pm

Looping repeating modules in a test case

Post by MarkW » Fri Feb 12, 2016 3:09 pm

Hello,

Apologies if this has already been covered but I was wondering if it was possible to loop through multiple modules in a test case rather than having to drag and drop the same module in multiple times?

My test case is testing the different possible combinations for invalid passwords when a user is required to change their password. I have modules for entering text into the Current password field and the new password fields, and a module for selecting OK and a final module for verifying the correct error message.

At the moment, I have repeated those modules for each possible invalid combination, which gives me the same 5 modules repeating 10 times (so 50 modules in the test case in total). At the end of the test case, I then try a valid combination and make sure the next screen appears correctly. I do it in one go because when you have an expired password, you can't close the system until you enter a new one.

Rather than having 50 modules in the test case, is there an easy way of just having 5 and then looping through them for each error combination, before breaking out of the loop to enter the valid combination?

Many thanks

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

Re: Looping repeating modules in a test case

Post by krstcs » Fri Feb 12, 2016 4:46 pm

One way to do this is to nest another test case inside your existing case. Give it a simple data connector with X number of rows, and drop the module you want to loop inside it. You don't have to put any data in the rows unless you want to (or your loop needs it).

Think of test cases in the suite as for-each loops:

foreach (row in dataConnector) {
do other test cases and modules here
}

You can nest them as deep as you need.

If you look at my response to your other post, I mentioned making modules as small as possible. This is one reason. You can drop exactly the modules you need into each test case, looping on only those modules that are needed for the inner test case.
Shortcuts usually aren't...