Iterate only modules within a test case

Ask general questions here.
kaancha
Posts: 17
Joined: Wed Oct 22, 2014 4:12 pm

Iterate only modules within a test case

Post by kaancha » Fri Apr 17, 2015 5:37 pm

I want to set up my test to run Login one time; the modules to do stuff multiple times; Logout one time.
Can that be all in one test case without having to write user codes?

Thanks,

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

Re: Iterate only modules within a test case

Post by odklizec » Fri Apr 17, 2015 5:55 pm

Hi,

It's possible with using nested TCs and data connector.
The structure of your test should look like this...

Code: Select all

[TC_1]
|_[Setup]
|  |_Login
|_[TC_2] there should be created data connector 
|  |_recording_1
|  |_...
|  |_recording_n
|_[Teardown]
   |_Logout
The data connector could be a simple one. Add as many rows as many times you want to repeat your recordings.
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

kaancha
Posts: 17
Joined: Wed Oct 22, 2014 4:12 pm

Re: Iterate only modules within a test case

Post by kaancha » Fri Apr 17, 2015 6:05 pm

Thank you for your quick response. In your solution, there are 3 test cases :
TC 1 : Setup >> Login
TC 2 : Modules where you suggested to iterate data
TC 3: TearDown >> Logout


My question was, is it possible within ONE test case?

Thanks.

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

Re: Iterate only modules within a test case

Post by odklizec » Fri Apr 17, 2015 6:14 pm

Hi,

There are no three test cases in my example, just two of them. Actually, there is just one TC and Test Suite root. The TC is the one with the data connector and recordings you want to loop. The Setup and Teardown sections are special sections available in each test case, including test suite (root). Just right click the test suite/test case and from the appeared menu select "Enable setup/teardown". Then you can add your login/logout recordings to these sections. I think there is no other code-less way to achieve what you want.
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

kaancha
Posts: 17
Joined: Wed Oct 22, 2014 4:12 pm

Re: Iterate only modules within a test case

Post by kaancha » Fri Apr 17, 2015 7:54 pm

Sorry for my confusion. Actually, the Setup and the Teardown should be outside of the TC ( Test Case).
This solves my problem. Thanks.

KevinKevin
Posts: 1
Joined: Thu Sep 21, 2017 6:40 pm

Re: Iterate only modules within a test case

Post by KevinKevin » Wed Oct 25, 2017 9:41 pm

I got the same problem in my work. I watched the Video (Data-Driven Test - youtube tutorial), but it seems looping every step, and i need to only loop some portion of my test (Sorry, i am not in Coding/programming). I need some help from you guys, thanks.

My Case:
1) Start/Login;
2) Setup some test data
3) some tests for many times - looping only for this step (excel file)?
4) some other tests, etc. and logout/end.

Only one variable in Step3 one (excel file and one column), the Video shows to select the Test Case (all steps) and bound excel file and then bound variable with excel column. So not sure if i can select Step3 and bound the file/variable to loop the data only for step3 (cannot try now)?

Any suggestion welcome.

Also can nested loop (loop inside another loop) possible without coding/programming? anyone tried this or any ideas?

mkendallm
Posts: 2
Joined: Fri Mar 25, 2016 9:15 pm
Location: Florida, USA
Contact:

Re: Iterate only modules within a test case

Post by mkendallm » Thu Oct 26, 2017 10:15 pm

Hey KevinKevin,

Inside the test suite you can have smart folders, and test cases. Both can have data sources attached to them, and they will iterate everything inside once for every row of the data source.

There is a requirement that each user code module, or recording module must have a test case as a parent somewhere in the tree. If you add a test case as the first child of the test suite, then you can add recording modules and user code modules here, as this satisfies the requirement that you must have a test case as a parent, but you cannot add a recording module to a smart folder which is the first child of the test suite, because this does not satisfy the requirement that a test case be somewhere in the tree of test containers in the test suite. The exception is that you can add a recording module or code module to the startup or tear down section of a smart folder, but this is the only exception inside the test suite, but it is also possible to add recording or code modules to the setup or tear down test suite itself without there even being a test case as a parent in the tree. My advice is to create a data source with a column called iterations, and values 1, 2, 3, 4, 5, then play around with smart folders, test cases, and setup and tear down sections (right click to add) until you become familiar with how these fit together.

There is another requirement that under each of the upper level test containers inside the test suite there can only be one test case. If you start with Test Suite > Test Case, then you cannot add another test case as the child of a test case, or as the child of a smart folder with a test case as a parent. This makes the smart folder the basic unit of organization of test containers in the test suite, and test cases are meant to reflect business requirements and test coverage.

After using the studio for quite some time, and the eventual addition of smart folders after version 7, I think starting with smart folders as the top level test container is fine, and then that way I can group my test cases below that according to business requirements, and then i can always have as many levels of smart folders as I require below that. Someone may be able to say why this won't work for them, but I think Test Suite > Smart Folder > Test Cases > Smart Folder 1 ( > Smart Folder 2 > Smart Folder 3...) should work for most situations. You can have as many levels of smart folders below the test case that you like, but you cannot nest test cases inside other test cases.

Setup and Tear down is where I put recording and code modules that do things that are required for the test, but aren't actually the test. I have come to prefer putting everything in smart folders. Test cases I use to designate that the business has a certain requirement. Setup sections have downgraded to the place where I put things if i absolutely have to check something is not happening before a test runs, or if I need to close all chrome browsers, etc., but even something as big as closing all chrome browsers is likely a good candidate for putting in a smart folder. Tear downs have an extremely useful feature to them, and that is they execute even if the test fails. This means putting close browser code in them (only an example) would help make sure the system doesn't have 100 browsers open on it because my test failed 100 times. Think about how to use tear downs to your advantage.

Reusing code comes in really handy. If you record yourself logging in, then make sure to split that up along logical lines, and you can just drag and drop that recording module where you need it to reuse the fact that you have already recorded yourself logging in. You can also right click steps of any module, and "move to new recording module", which is very useful for splitting things out into their own modules. Drag and dropping steps works too though.

KevinKevin, as for the 1, 2, 3, 4 you have provided below consider the following setup:

Code: Select all

Test Suite
    - Setup: Do your startup stuff here.  Clean up the system to get ready for testing, etc.
        - Smart Folder: This is your first grouping of test cases
            - Test Case 1: open browser, login, iterate, logout, close browser
                - Smart Folder: open browser
                - Smart Folder: login
                - Smart Folder: iterate, data source. only the contents of this smart folder will repeat
                - Smart Folder: logout
                - Smart Folder: close browser
    - Tear down: do things to clean up the system after failure or test completed
Of course you still may want to use setup and tear down sections of smart folders and test cases, and I often do use them, but I don't plan to use them as much.

Say in the above example I designed the test to login as one user, push five buttons, and logout. My boss comes to me and says "Great! Now I want you to do the same thing for this list of users". No problem! Just add a new smart folder just after the "open browser" smart folder above. We still have all the smart folders as children of Test Case 1 at this point. Now drag and drop the login, iterate, and logout test containers into the new smart folder you created, and you have something that looks like this with a new level under the new smart folder we added:

Code: Select all

Test Suite
    - Setup: Do your startup stuff here.  Clean up the system to get ready for testing, etc.
        - Smart Folder: This is your first grouping of test cases
            - Test Case 1: open browser, login, iterate, logout, close browser
                - Smart Folder: open browser
                - Smart Folder: This is the new smart folder we added
                    - Smart Folder: login
                    - Smart Folder: iterate, data source
                    - Smart Folder: logout
                - Smart Folder: close browser
    - Tear down: do things to clean up the system after failure or test completed
Now we can add a data source to the new smart folder we created that has login, iterate, and logout as children. It will now iterate login, iterate (yep, iterating a test container that iterates), and logout. I can bind variables like username and password to the new data source my boss gave me, and take the rest of the day off, because she thought it was going to take me all week to accomplish that task.

Here is an exercise:
How many times will it print "Hello World":
Test Suite > Smart Folder (Data Source 2 rows) > Smart Folder (Data Source 4 rows) > Smart Folder (Data Source 8 rows) > Recording Module (just prints "Hello World!"). There is a bonus answer, but a number is also fine.

To save yourself even more time you will want to look into module grouping. It is always pretty useful to break automation steps out into their own modules, but every once in a while you'll notice you're using the same three or four modules in a row. Time to use module grouping.