How to skip the Set Up if previous test case is pass?

Ask general questions here.
Posts: 7
Joined: Wed Feb 19, 2014 3:27 pm

How to skip the Set Up if previous test case is pass?

Post by ChrisDavid » Tue Aug 19, 2014 2:00 pm


We are looking to reduce the time taken for each run. We have suites which has about some 80+ test cases and runs for almost 6+ hrs. In which set up and tear down in each test case runs for some 3 mins. so we are looking to cut down some 2 hrs by skipping the set up process if the previous test case is passed. Consider that set up has login to 2 applications(2 code/recording modules) and Teardown has logout scripts for that 2 applications(2 code/recording modules). I need to do the below,

1) Run the set up in 1st Test case
2) Run the test case
3) Check if set up and other tests are passed
3.a) If passed skip Teardown
3.b) If failed run Teardown
4) Check if previous Set up, Tests, Tear down are passed(Skipped teardown is considered as passed)
4.a) If Passed skip Set up
4.b) If any got Failed run Set up
5) 3 & 4 continues for other Test cases
6) Run the Tear down for last Test case

Can anyone say how we can achieve this?


Posts: 7
Joined: Wed Feb 19, 2014 3:27 pm

Re: How to skip the Set Up if previous test case is pass?

Post by ChrisDavid » Wed Aug 20, 2014 2:01 pm

Can someone please say if this is possible with ranorex? This can be helpful for many.

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

Re: How to skip the Set Up if previous test case is pass?

Post by krstcs » Wed Aug 20, 2014 2:27 pm

I don't think it is possible without some serious user-code manipulation, and even then it might only be possible if using hacks, which makes it more problematic than just running the setup/tear-down every time. For example, there is a way to "Check" and "Un-check" the test cases in the suite from code, but I don't think this applies to setup/tear-down or individual modules, but I could be wrong.

A few things to think about:

1. Ranorex is a functional UI test automation tool, so it does the same things a human does with the UI. The more it has to do, the more time it will take. It runs faster than a human, but it isn't instantaneous (and really, the speed of the test isn't the biggest benefit, the consistency is). So, if you are trying to implement test automation in the context of software builds (similar to Unit Tests), you will be disappointed. To me 2-3 extra minutes during setup/tear-down is not very much, even on the scale of adding a few hours to 6 hours of testing. Maybe you can run your tests at night when nobody is waiting on them.

2. Build out your test environment so that you can run more tests in parallel. Unless test B actually requires test A to be finished, why not run them concurrently? From your description of having that many setup/tear-down regions, it sounds like your test cases are not dependent, but I could be reading something into it that isn't there.

3. You might look at how to restructure your tests to make those areas not necessary instead of including logic that will be harder to maintain in the long run. Also, restructure your XPaths so that the objects are found more quickly. If you are waiting for things to exist or validating that they don't exist, this will take time (up to the object's timeout). Try figuring out a better way to make the validation. Try shortening the timeouts of those objects (as long as the shorter time doesn't impact other areas). Make duplicate objects that have short timeouts and use those for the validations/waits where you expect the timeout to be fully met.

Without knowing your setup and what you are testing, these thoughts are just thoughts and might not reflect your real-world needs. I'm just throwing stuff out there to see if any of it helps you with your situation.
Shortcuts usually aren't...