I have hundreds of tests and when I run them on an iOS device over night, then next morning I check my results only some tests complete and then the rest of the tests get this error in Visual Studios error list.
The testcase because of which Testsuite is crashed. If u run it individually does it works ? If yes some issue with Appium if no then locator to be changed.
Thanks for your input. When running each test individually it seems fine. But I think it might have to do with driver.ResetApp(); but it could also be Appium, like you said, or something else…
I am still looking into it.
I might try to run my tests on a simulator and see if this happens there as well.
I’ll update the thread with findings as I find them.
Hey there.
I’m not sure to the details of your tests, but I used to call $driver.reset (in ruby), then stop and restart the driver to continue the tests.
I ran into the same problem. Things would crash - I would mainly get “App failed to resume in time”. I tried putting delays in. It helped slightly but ultimately the crash came back.
I wound up adopting a --no-reset model and just fail out once a major checkpoint failed.
It’ll be interesting to see what you come up with.
Hope this is helpful
Eric
when you say you ended up adopting a no-reset model, did you mean getting rid of driver.reset and only setting the capabilities flag ‘fullReset’ to true?
Could you also please explain to me a little more about failing out once a major checkpoint failed?
I found a similar thread on github about test suite stop running half way through here,
I start Appium as described below with the –no-reset flag. I write my tests whereby at the end of each scenario they arrive at the same state as before. In my case, logged out.
For iOS
appium -U ${udid} -a localhost -p $ios_appium_port --no-reset &
where: udid = iOS device unique identifier
where: ios_appium_port= port that appium runs on for iOS
For Android
appium -a localhost -p $android_appium_port -bp $android_appium_bootstrap_port --no-reset &
where: android_appium_port= port that appium runs on for android
where: android_appium_bootstrap_port = appium bootstrap port for android
As I mentioned, just from a cleaner standpoint, I fail out once I encounter an error. Because I do not know what the severity of that error is, or what state the app may be in - I figured it was best to do so. (At some point I may revisit this and have varying levels of errors). Alas, to achieve this point in ruby/cucumber, I add this to my hooks.rb file:
After do |s|
# Tell Cucumber to quit after this scenario is done - if it failed.
Cucumber.wants_to_quit = true if s.failed?
end
At the beginning of each test run (once only), I uninstall and reinstall the app to get to a clean state.
I read over your github issue. I don’t know why Appium would crash after a given amount of time. While I think that’s good to have that issue addressed, one way to avoid this is to compartmentalize your test runs. In Ruby/Cucumber, you can add tags to any set of scenarios you want, and then set up your cucumber.yml file and Rakefile to initiate only those tagged tests.
Hopefully this helps. Let me know if you need any more information.
//Already set the noReset flag to true @Test
public void testSomeThing()
{
syso(“Do something”)
} @AfterMethod
public void closeApp()
{
driver.closeApp();
} @Test
public void WantToOpenAppWithoutResetinIos()
{
driver.launchApp();
//carry on with testing
}
But the prob is that simulator is getting reset after each test; any pointers on solving the isse
i dont wnat to reset the ios simulator after each state ; i want to use the data entered in test 1 to be used for test2 .
I can’t say I’ve figured out exactly what caused the issue yet. But I recently updated my xcode to 7.0 and I have not seen my tests crashing half way ever since.
Hmm. Interesting. I’m wondering if there were any enhancements to UI Automation were done for Xcode 7. I think things are going to get a lot more stable as Apple enhances its xcuitest framework and Appium takes full advantage of it.
