I use squish for testing and it doesn't close the tested application correct always. In that case office (Word, Excel, PowerPoint) starts with some recovery options (previous documents getting restored, some dialog windows appear, etc) I need to reset the status of the application before the start of new test.
Asked
Active
Viewed 41 times
1 Answers
1
Isn't it better to close the Office application properly?
For example, you could automate Office application using Automation. The recovery options mean the host application was not closed gracefully or something unexpected happened with it (crash?). So, I'd recommend asking squish developers what is wrong with their software other than looking for a workaround to suppress evidences.
Eugene Astafiev
- 47,483
- 3
- 24
- 45
-
Squish comes with some sane default behavior, like ensure kill automated applications if still running upon test script exit (to avoid that the lingering app causes other issues). Closing applications gracefully is not always possible on Windows (and not done by Squish anyway), the test script should ensure to close the app in a suitable way. Squish allows declaring a function called "[cleanup()](https://doc.froglogic.com/squish/latest/api.special.functions.html#api.special.functions)", which could do this once the main() function exited. – frog.ca Oct 14 '21 at 11:47
-
Killing processes is not the right way to stop them. Squish developers don't care about users then. – Eugene Astafiev Oct 14 '21 at 12:22
-
Eugene, given what you just said, it does not sound like you are familiar with the requirements of automated GUI testing. 1) App must be closed before next test case. 2) App may plain not quit. 3) App may have modal dialogs that prevent closing its windows (assuming window closing quits the app). 4) Closing app dialogs may result in further dialogs, endlessly. 5) Closing app windows may not close app. Last, but not least, killing is useful for automated GUI testing as it exercises the often ignored case of the process finishing in un-orderly fashion (power outage, crash, killed by user). – frog.ca Oct 15 '21 at 13:42
-
Eugene, if you have ideas how to address these points in a way that does avoid the need to kill the application, please let me know, I will happily forward them to the developers of Squish GUI tester. – frog.ca Oct 15 '21 at 13:44
-
Instead of killing processes you need to wait for some time and let the host application be closed. Each Office application has the `Close` or `Quit` methods that does the job. If the application is not closed - that is a good indicator of not release underlying COM object references in the code. Typically the application closes correctly, if it doesn't - the problem is in the automation code. – Eugene Astafiev Oct 15 '21 at 15:01
-
Eugene, before you can wait for an application to close you need to be able to trigger its closing. And this is (in theory and practice) not 100% possible for the above reasons. However, it is possible for the user to implement this in a way suitable for each specific application in a simple manner that is identical to any other GUI automation that one does in Squish. – frog.ca Oct 18 '21 at 11:07
-
There are workarounds to close dialogs from Office application. Just killing processes/applications is the most easiest way. – Eugene Astafiev Oct 18 '21 at 12:05
-
Eugene, Squish could make assumptions about the behavior of all versions of all MS Office software, across various configurations, and while at it, on all other software on the market that everyone deems "essential". Instead, Squish focuses on GUI automation and leaves it up to the user to provide a suitable solution for their specific setup and cases, for which Squish provides the means. If you define this as "does not care about users", then we can agree, but disagree on the definition. PS: No word from you on the "unexpected" cases I mentioned, like a process simply not closing.
– frog.ca Oct 19 '21 at 15:05