Is there way to run our code on an existing browser instance without relaunching?

[Sunil]

Is there any way we can run our code with out launching the browser each time we debug our code, this is the problem if we are debugging certain code in middle and we need to run the whole code.What I mean to say is tht is there any way where we can capture all the browser instances on desktop and then compare the required browser title with our string and then work on that browser instead launching a new instance,
Just a thought to improve our debugging response time, please suggest on this, thanks!

[Velin Koychev]

Hello Sunil,

Currently we do not have the ability in the framework to connect to an already opened browser. It is mandatory that it open a new browser in order to control it. This feature is currently available in Test Studio.

Thank you for your understanding.
 
Regards,
Velin Koychev
Telerik

[David]

Hi Velin,
Is this function likely to be implemented in the future?
When you say, "...this functionality is available in Test Studio", what do you mean? The Test Studio link you sent takes you to a Telerik advert that doesn't appear to be connected with this issue. 

Cheers
Dave

[Velin Koychev]

Hello Dave,

As I said, it is already here.
You can use this option from Test Step Context Menu:

• Run - execute the test to or from the selected step. Run bits of the test without having to run the entire test.
  • To Here - launch a new instance of Internet Explorer, execute the preceding (and selected) test step(s), and enter recording mode.
  • From Here - execute the subsequent steps in an existing browser instance (must have recording toolbar attached).
  • Selected Steps - execute the selected steps in an existing browser instance (must have recording toolbar attached).

I hope this helps.

Regards,
Velin Koychev
Telerik

[David]

Hi Velin,

I think I am confused by a slight ambiguity in what you are saying in your statement: ""Currently we do not have the ability in the framework to connect to an already opened browser. It is mandatory that it open a new browser in order to control it. This feature is currently available in Test Studio."
As I read it, it appears you are saying its not possible to to connect to an open browser, then in the next sentence you are saying it can be done because there is a feature in Test Studio to do it.   Are you, in fact, talking about 2 different situations:  Firstly, it is possible to work with in an open browser and repeatedly run some, or all the steps of a given test during the development/debugging of a test. Secondly, it is not possible to have a test open a browser and then have subsequent tests run in the same browser?

One question about the instructions in your last post, what do you mean by: must have recording toolbar attached? how do you attach a recording tool bar?

Cheers
Dave

[Cody]

Hello Dave,

I apologize for the confusing statements by Velin. I will try to clear up where the confusion is coming from.

• Velin is correct in his statement "Currently we do not have the ability in the framework to connect to an already opened browser". He's referring to our free Telerik Testing Framework product.
• Velin is also correct in his statement "This feature is currently available in Test Studio". He's referring to our commercial Test Studio test automation product. Our record and playback product can attach our recorder to an already opened browser for the purpose of recording additional steps to a Test Studio test. This is what he meant by "must have recording toolbar attached".

I will admit neither product is able to connect to an already opened browser during test execution. It's only our Test Studio product that can attach our recorder to an already opened browser.

So now the question to you, which product are you trying to use? This thread is entered in our "Telerik Testing Framework" forum which is dedicated to the support of our free Telerik Testing Framework.

Regards,
Cody
Telerik

[David]

Hi Cody,
Ok, I see were the confusion occurred,  I was Assuming Velin was using "framework" and "test Studio" to refer to the same thing.
We have Test Studio - functional.  
Given that, that me clarify what we can and can't do:
 - I can work with a persistently open browser while developing test cases.
 - I cannot interact with a persistently open browser when running tests that contain test as steps.  Each test as a step has to work within new instance of a browser.
 - if I put my tests in a Test List, rather than as tests steps within a test, I can enable ReycleBrowser test list setting to prevent the browser running between tests?

Cheers
Dave

[Cody]

Hello David,

I cannot interact with a persistently open browser when running tests that contain test as steps.  Each test as a step has to work within new instance of a browser.

Sorry for the confusion on this, actually the opposite is true. When calling a subtest via our Test-as-step feature the browser will always remain open so that it acts like one long single test.

if I put my tests in a Test List, rather than as tests steps within a test, I can enable ReycleBrowser test list setting to prevent the browser running between tests?

In our Test List settings is a "Recycle Browser" setting. The default setting is False, which means close the browser when the current test (excluding Test-as-step) is finished and launch a new browser to run the next test. If this is set to True, the browser will launch for the first test, stay open for all tests, then close after the last test in the entire test list has finished.

Regards,
Cody
Telerik

[David]

Hi Cody,

Just a follow on point of clarification, that ties in with a discussion I am having else where: 

Given that "When calling a subtest via our Test-as-step feature the browser will always remain open so that it acts like one long single test", if there is a step in there that is data drive all the steps including the test as a step will be iterated over.  So I couldn't not put a login test as a step, in a test with other steps that are iterates through 5 times, if I only wanted to login once.  The login would be iterated over as well.  To login once and iterate five times I have to break this out as two tests and put a test wrapper around it or put it in a test list

Cheers
Dave

[Cody]

Hello,

To handle the scenario you describe I would create 3 tests:

• A - parent test that simply calls two subtests, test B and test C. This test is NOT data driven. You could have this test to the NavigateTo step if desired. Or put the NavigateTo step in test B. Either method will work.
• B - Common login sub-test. This test is NOT data driven.
• C - Actual work. This test is data driven and assumes the browser is already opened and the user is logged in.

When you run test A, the sequence runs like this:

1. The browser launches
2. Test A gets control
3. Test A passes control to test B.
4. Test B performs the logon
5. Test B ends and control is returned to test A
6. Test A passes control to test C
7. Test C, being a data driven test will run N number of times, once per row of data. Since non of the other tests in this scenario are data driven, they will only run once.
8. Test C ends, after running through all data iterations, and control is returned to test A
9. Test A ends
10. The browser is closed, results are stored and test execution is completed.

Does the above explanation help?

Regards,
Cody
Telerik

[David]

Cody,
Yep, that make sense; to make sure let me summarize:  The work flow is broken into sub-tests according to which steps are data driven. A wrapper test is then used to string the sub-tests together.  This gives us control over the steps that are iterated in a given work flow, and avoid dependencies on Test Lists.

Cheers
Dave 

   

[Cody]

Hello David,

Yes you got it! I like to call it "test modularization". It's the same basic concept as functions in the software programming world. You write a bunch of common functions which are called as needed by the main program. This approach minimizes duplication of code and even makes the main program more readable to us humans.

I am closing this ticket as resolved. You may reopening if needed.

Regards,
Cody
Telerik