Verify statements fails after 30sec. with the error "Unable to find the window 'PopupWindow' inside WPF application

Progress® Telerik® Test Studio® Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Completed

Last Updated: 20 Aug 2015 13:26 by ADMIN

ADMIN

Ivaylo

Created on: 03 Dec 2014 09:40

Type: Bug Report

Verify statements fails after 30sec. with the error "Unable to find the window 'PopupWindow' inside WPF application

Project and application for repro attached internally. In customer own words:

Issue1:

See test: "Verify step timeout after 30sec"

Explanation:

Verify statements fails after 30sec. with the error "Unable to find the window 'PopupWindow' inside application <XYZ>"

So it launches the WPF test app.

Step2 completes ok.

Now pay attention to "Step7" which is : Verify ExistsNot 'SomethingTextblock'

Then it verfies that the SomethingTextblock does not exists.

Note: 'SomethingTextblock' is an element located on another page called "PopupWindow".

It does this a a verification step, which means: it should instantly without any delay verify the DOM against the existence of the desired element.

Why does it timeout 30sec ?

Where is it blocking ?

I attached a VS debugger and easily concluded where it gets stuck.

It calls : Applications.wpfAppexe.PopupWindow.SomethingTextblock

In fact it blocks right here: = > Applications.wpfAppexe.PopupWindow

For reference look up Pages.g.cs

...

 public PopupWindowWindow PopupWindow

 {

  get

  {

   return new PopupWindowWindow(this.OwnerApplication.WaitForWindow("PopupWindow").Find);

  }

 }

So the verification step internally accesses the "PopupWindow" getter, as referenced above (pages.g.cs).

It then calls "WaitForWindow" with a single title parameter.

WaitForWindow also has a 2nd optional parameter, which is a timeout parameter.

If this parameter is not specified then it defaults at 30 sec.

This is why it is waiting those 30sec

Since All window access in the pages.g.cs is defined as WaitForWindow("SomeThing").Find

.. without the timeout defined.

But back to the step 4: Verify ExistsNot 'SomethingTextblock'

It should immidiately return me a result, which would be "success".

As the element does not exist.

you can also checkout the test "Wait ExiststNot step fails when closing dialog" which is more or less the same issue.

4 comments

ADMIN

Konstantin Petkov

Posted on: 15 Jan 2015 13:27

Hi Elo,

We investigated the scenario and were able to pinpoint the issue thanks to your detailed description. Fortunately we have a quick solution for you.

As you first figured out it's the WpfApplication.WaitForWindow() which waits for the window for specific timeout. This timeout in the WPF automation framework actually corresponds to the ClientReadyTimeout setting, which you can control regardless the execution:
- In Quick execution it is exposed up there in the Ribbon along with the Wait On Elements timeout setting.
- In Test List execution you have that exposed in the Test List settings as well.
- In framework test you can access it from the common Settings class.

It basically waits for the window (as the actual client) to get ready and has default value of 60 seconds with the latest releases. Setting like 1 second for sample testing purposes is just fine and the verify step fails shortly. Such a short timeout value isn't fine in general though since real applications may need more time to get their windows initialized.

In fact this is similar to the "connect to popup" execution behavior in Web with the difference the popups have their own ready timeout setting as part of the specific "Connect To" step type. There is no separate test step to handle connect to window in WPF though.

Please let us know if this makes sense for you and if you need further assistance.

Thank you!

ADMIN

Konstantin Petkov

Posted on: 07 Jan 2015 08:28

Hi Elo,

Thanks for your feedback!

We will definitely look into what can be done to improve this particular WPF execution scenario referring the element in code. 

I have to admit we do have specific differences between the Web and WPF automation framework. Trying to change the WPF automation framework in general to match the Web experience may result in a number of breaking changes though, which we would definitely like to avoid.

Thanks for the understanding!

Best regards,
-Konstantin

Elo

Posted on: 19 Dec 2014 07:36

Your description of how it works is also how I see it.
Atleast this is good :)

But the workaround is rather bad I think - so is the implementation.
Talking about the workaround - Why not just use  "~" for window title ?
Obviously all my elements will now be categorized under one single page.

If you have worked on telerik web tests then you will get confused when you apply your 
webtesting-experience to the world of WPF testing in test studio.

As it is now WPF vs WEB testing is not 100% transparent to the test developer.

In web testing you do not have these silly limitations.
In WPF testing verify and wait steps are basically the same. Just try and convert each of those variants to a coded step and they produce the same lines of code.

In web testing verify and wait are different. So should it be in WPF testing.

This behaviour you describe will this change or will it be this way for good ?
Do you have a future desire of changing this ?
If you do not plan on changing this I would like to hear your thoughts on why you think this current design is the way to go ?

We are currently internally reviewing wether or not to continue using telerik test studio for WPF testing as this is one of our major pain points.

regards
Elo

ADMIN

Daniel Djambov

Posted on: 15 Dec 2014 09:01

Telerik: this is how the elements recognition currently work - each element is searched inside the parent window it resides in. If element A is in Window1 and element B is in Window2, when performing verifications/actions for element B while its parent window B does not exist it will throw this timeout exception that the parent window is not present and will not reach to execute the verification/action step at all, will stop at this top level verification for the window. If you have this implementation in mind, you can properly build your tests and verifications. For the specific case you have provided, the first element in under window called MainWindow and second element in under window PopupWindow, which is not present at execution time and exception is thrown. A workaround for the the test to work would be to use relative names as window caption in Elements Explorer, i.e. if you rename the Caption property of the "MainWindow" to be "~Window" and then rename "PopupWindow" to have same caption "~Window", both parent windows will be merged into one window with caption "~Window" and all elements will belong to a single new window, thus running the test will not throw the exception it cannot find the window and will execute successfully the verify ExistsNot step. However this approach can be used in limited cases where windows captions have something similar and can be merged.