We have a large java swing based application with many modal pop ups and windows. In our project properties -> playback, under "On Unexpected window" I have enabled the checkboxes that press 'esc', 'enter', 'send the close command', and 'click on focused control'. However this has never worked (even since TestComplete 😎 when we encounter unexpected windows from our application. I am wondering if those modals/windows that show up unexpectedly during the test are not considered an "unexpected" windows to TestComplete, since it is still part of our application.
If that is the case, we would have to write specific handlers depending on which modal/window exists (ex: if (Aliases.blah.exists(1000) do....) which would be very slow and unnacceptable.
Is there a way to define which windows would be "unexpected" or some other alternative solution?
This may be of some help. It explains how TestComplete is handling the unexpected windows. Be sure and read the Remarks section at the bottom of the article.
I have looked at the remarks, all of our popup windows are visible and of type java.swing. From my conclusion and as stated in the documentation, expected behavior is defined when recording the test, and anything outside of that is considered "unexpected".
This means that, for example, whn trying to close our application, if there was a popup saying "your changes may not have been saved" which has never showed up before, it would be considered an unexpected window correct? We have had this exact scenario happen with the unexpected window handler not working... is there anything we can do?
Thanks for the quick reply,
> Is there a way to define which windows would be "unexpected"
The window is considered to be unexpected in TestComplete (with the triggering of the OnUnexpectedWindow event) if this window blocks UI action on some other window object that test code tries to perform.
As a rule, unexpected windows are detected when test code tries to .Click() or .Activate() some object and this action is blocked by some other window.
For example, if test code entered wrong data into a form field and this caused display of modal warning window and test code tries then to click the OK button on a form, the click will be blocked because of the modal window and OnUnexpectedWindow event will be triggered.
On the other hand, if test code explicitly checks modal warning window existence and handles the window if it exists, then OnUnexpectedWindow will not be triggered.
Also, for the above example, if after the modal warning window was displayed test code assigns a value to some other field on the form via the .SetText() method, the OnUnexpectedWindow event will not be triggered either because .SetText() method does not interact with UI but makes assignment via non-GUI function call.
Thanks for your reply. I work with the OP who is off today so I am going to answer in his place to help us get to the bottom of this :-).
So, your example of " if test code entered wrong data into a form field and this caused display of modal warning window and test code tries then to click the OK button on a form, the click will be blocked because of the modal window" is exactly what is happening. You say however that "an OnUnexpectedWindow event will be triggered". Ok, so that is following with the documentation we see in a link like this: https://support.smartbear.com/testcomplete/docs/testing-with/running/handling-errors/unexpected-wind... where it says that TC waits until the auto-wait timeout period expires, then fires OnUnexpectedWindow.
What we are really curious about is why step 3 on that page is not happening, where if the window is not closed by the handler, then TC goes through a series of steps to close the modal - pressing ESC key, pressing ENTER key, sending close command to the window. We can't seem to get this behaviour to happen - right now if a modal pops up and we do not have a handler for it it is just failing our test because TC is never closing the window. We have an understanding from the docs that TC can and will handle these modals without us having to specifically code for them....?
We have used TestComplete for 6 or 7 years now and are on our second iteration of creating tests for our application. We cannot now, nor have we been able to in the past, get the automatic handling of unexpected windows to happen. Our previous GUI test code we coded some special handling for all unexpecteds, but this time around would like to see if we can get TC to handle it and save us some of the work involved.
> why step 3 on that page is not happening
Have you checked settings mentioned for the first two paragraphs of step 3?
According to the documentation, TestComplete tries to close unexpected window only in the case when it is not commanded to stop test run. If, according to settings, test run must be stopped, then TestComplete does not try to close the unexpected window.
All of our error handling settings tell TestComplete to Continue running on error, on object recognition error, and on warning.
I have attached an image of our TC settings.
What about Test Items settings (https://support.smartbear.com/testcomplete/docs/working-with/managing-projects/project-editor/test-i...) mentioned under first bullet for the step 3 being discussed?
All of our test items use the project's 'On error' property, which in turn is configured to continue running in the event of any errors. Are there any other settings that may overwrite this, or any other checks we should do to make sure the "on unexpected window" behavior is reached?
How to execute remote test and obtain results via Test Runner REST API
Comparing content of HTML table with Excel file data
Compare HTML table with Excel file and correct data in the file
Retrieve Data from a Web Page