Breaking up Tests into Re-usable Steps when using Env Variables

Hello Ray,

As far as I understand you would like to be able to debug a nested test by running all previous steps in the parent one, including if these are other tests as steps.

If this is correct, then you can use the Visual Debugger options in quick run mode and set breakpoints for the desired step, where the test should stop. Breakpoint can be set in the steps pane - please, see the red dot on the screenshot in this article. The resources you can use in the Visual Debugger are listed here. 

Having that said, here is an overview of what you can give a try to:

• include a breakpoint for the 3rd step inside Page1Step test
• open the ASmartTest, which is the parent test
• select the  Page1Step test as step and hit Run->To Here

The expected outcome is that all steps listed before the breakpoint step - 3rd step inside Page1Step test, will be executed and you will be able to continue debugging in that context. 

I hope this will work for you as well. Of course, if facing any troubles, do not hesitate to get back to us.

Regards,
Elena
Progress Telerik

I think this will be exactly what I need when I can make it work. So far, it is not working quite as expected.

I have a test:

    Test1:

        Step1: (3 steps inside this)

        Step2: (5 steps inside this)

I put a breakpoint on the 5th step inside Step2. From the Test1 step list, I selected Step2 and used 'Run -> To Here'.

All of Step1 and Step2 executed. The execution of Step2 did not stop at the 5th step.

I will see if there is some option I have to check or something else I need to do.

much thanx - ray

Hi Ray,

Thank you for checking out the provided suggestion and sharing your observations. 

I reviewed once again the breakpoint behavior and noticed I have misled you in my last reply - please, excuse me for any inconvenience caused.

So here is what I have messed up - the partial run using the Step context menu options Run-> To... is not actually triggering the Visual Debugger. This is so, as this is partial execution and as such you will be able to explore any details you need in the active recording session once the selected steps are executed.

The Visual Debugger, though, pops up if you click the Execute button to run the whole test. This is where the breakpoints will take place as well - the execution will be paused at the step with breakpoint and will allow you to explore the DOM tree, execution log, etc.

Please, check if this will work for you. Thank you once again for your cooperation.

Regards,
Elena
Progress Telerik

Hm. Well, that works. So, much thanx.

It is odd, though, that selecting the Run menu item in the Project pane is not the same as clicking on the Execute button in the Tests pane. It seems that they should do the same thing.

Wow. I just realized something about the Tests pane.

I have been doing everything from the Project pane. But when I had to stop a test in mid-run, I would have to close the browser window and sometimes I would have to manually close the command execution window. And then the UI would be in an odd start. I would select a test and get the context menu and "Run Test" would be greyed out. So I could not run a test.

I was then quitting TS and re-launching.

Well, I just realized that if I switch over to the Test page, the Execute button shows that the test is still running. I can cancel the test there and then I can run the test again without re-launching the entire application. How wonderful!

Hello Ray,

I am glad to know you are few steps further in sorting out the best way to troubleshoot your tests. 

It sounds really strange that you see difference in the execution if triggered from the Project pane or the Execute button, when a test is opened. So, I tested this on my end and it works consistently for me - in other words, the Visual Debugger is launched for the two types of starting the test run and the set Breakpoint is respected and the execution is paused. I will appreciate if you record a short video demonstrating the differences you see on your end - you can use a really simple test with only few steps to showcase this. Of course, this is not a high priority investigation, so you can get back to it, when you have the time for it. 

Apart from this, I want to mention that starting and terminating the test execution process takes some time. So, even if you forced close the browser, it should return to working state again, after few seconds. Depending on the test and machine in use this may last even more than half a minute. 

Anyways, it seems that the findings in this discussion will help you have more consistent experience with Test Studio. Of course, if there is anything else I can be helpful with, please, do not hesitate to get back to me.

Thank you for your cooperation once again.

Regards,
Elena
Progress Telerik