09-13-2017 09:44 AM
Sometimes I face the issue with starting my TestedApp. The issue appears on virtual machines, tests are executed by TestExecute via Jenkins.
I use TestedApps.myapp.Run() in my OnStartTest event. TestExecute says 'Waiting for myapp' and cannot start it unless I start it manually. After that for several tests it can successfully start the app. Later it can either successfully start the app for all tests or 'hang' again.
Since the issue is not stable I can't come up with any ideas on how to fix that.
09-13-2017 11:38 PM
If the same code and configuration works fine except sometimes then better to raise support ticket to get the info.
you can that here: https://support.smartbear.com/message/?prod=TestComplete
“You must expect great things from you, before you can do them”
09-14-2017 05:56 AM
I wonder if it's a "permissions" thing in some way? Are you running your tests via Jenkins where the tests are running with elevated permissions to an administrator level? I'm not a Jenkins users so I wouldn't know what to do to accomplish this. Something you can try is to manually execute the command line on the machines on which it fails and see if you can get it to fail outside of Jenkins, just in case it's in something in that implementation.
09-14-2017 09:26 AM
So, it's one particular app in one project within the larger test suite.... interesting. Can you post a screenshot of how that app is configured in TestedApp?
09-14-2017 09:46 AM
All projects within your suite run this same app I'm assuming?
I wonder, with regards to your VM, if the problem is that the process for the application is remaining memory resident after you close it. So, when you go to execute the tests and run the application, it says, "Oh, there's already an instance running, I'll just wait for it to become responsive", hence the wait message.
I would add some logging into your tests, just to debug. Right before you call the command to run your tested app, do an "If object" Exists check to see if the process is memory resident. If it is, log a message and then call the process's "Terminate" method and see if this resolves your problem.
09-14-2017 10:04 AM
Thank you for your reply, tristaanogre
I do all the verifications (kinda 'if the process exists') and before the app is expected to run it first tries to close via UI, if not - tries to perform Close(), if not - performs Terminate().
From what I remember the behavior is as follows.
When it says - there is 1 instance of the app running, cannot start another instance - it moves forward the test and does not hang.
When it actually cannot start the app it says smth like Process not found. I will wait for the test execution to complete and share the messages I get there.
09-14-2017 10:15 AM
Would love to see what sort of message you're getting.
However, one other thing to look at...
Something "new" I learned at SmartBear Connect was the difference between "Run" and "Launch" with regards to TestedApps. Run will wait for the application process to return before it continues. "Launch" will launch the application and then keep going.
So... what it sounds like is that the application is being "Run" but there is some sort of long delay in actually having the process return. So, I'm still curious as to whether or not the process for your application is memory resident after the failing "Run" command. If not, then there's something going wrong with the launching of the application. Perhaps, still, a timing problem that the closing of the application from a previous test is not closing the application fast enough so that, when the next project kicks off, it gets the "Run" command while the process is still resident in memory but then it goes out of memory before it can return the process... Again, something with timing is my guess. What you can try is change the command to "Launch", add code to check to see if the process is present.... if it's not after x number of seconds (while loop), try "Launch" again... repeat a specific number of times until you determine failure and then log an error, stop the project, and move on.