Hello,
In our company we are using the following setup to execute our Appium Android tests:
Appium Version: 1.17.1
Java: OpenJDK 11
Cucumber JVM: 5.4.0
Appium Java Client: 7.3.0
IDE: IntelliJ 2019.3
Device: Pixel 2 emuatlor
Android OS: 9
At this current moment we use the fullReset capabilty to ensure that we have a clean slate before each test starts. For some unknown reason this capability has stopped working this afternoon. More to the point none of the reset strategies appear to be taking effect after the first test has been executed (including the default one)
To try and triage what’s going on I’ve ran the same 2 tests from 2 separate branches in our codebase (master and my dev branch) On Master the capability works whereas on my dev branch it doesn’t. I was therefore confident that it is something in our code but when I trawl through the logs I can see that the reset call on the dev branch (something like this 2020-05-26 21:53:48:379 [W3C (436d74fe)] Calling AppiumDriver.reset() with args: ["436d74fe-b867-4b51-a545-be68def10854"]) is completely non existent between when the first test finishes and the second one starts. Appium is therefore thinking that the test hasn’t finished hence all following tests start to fail.
After seeing the above I can no longer be sure that the issue relies in our code. I was therefore wondering if someone with more Appium experience than I could be so kind as to look through the attached logs to see if I’ve missed something obvious.
Master works and dev doesn’t. The capabilties used on both branches are:
“platformName”: “android”,
“app”: “/Users/tonyskinner/Workspace/mobile-ui-tests/src/main/resources/apps/androidApp.apk”,
“appActivity”: “com.depop._v2.app.splash.SplashActivity”,
“appPackage”: “com.depop.vendor”,
“automationName”: “UiAutomator2”,
“chromedriverExecutableDir”: “/Users/tonyskinner/Workspace/mobile-ui-tests/src/main/resources/apps/chromeDrivers”,
“deviceName”: “Pixel2”,
“fullReset”: “true”,
“language”: “en”,
“locale”: “GB”,
“platformVersion”: “9”
Many thanks in advance.
appium_dev.log (125.1 KB) appium_master.log (49.8 KB)
we see in dev:
2020-05-26 21:52:10:187 [ADB] Uninstalling com.depop.vendor
...
2020-05-26 21:52:45:906 [ADB] Uninstalling com.depop.vendor
and then test stops and looks like second test did not start
in master we see it 3 times.
Hello Aleksei,
Many thanks for taking a look at this.
That’s intriguing, because the second test most certainly starts at the Cucumber level on the dev branch. From what I could make out in the Appium logs, Appium’s treating the second test as though it’s a continuation of the first. This is because it responded to the client with a 200 for the click event on the alreadyHaveAccountButton, before then going onto wait for it again.
As part of the fullReset capability we’re starting from the main entry point of the app each time (because as I’m sure you’re more than aware fullReset does a reinstall of the app), so both tests start by waiting and clicking that button.
Attached are some screenshots which confirm the same. I’ve commented out the latter steps on the 2 tests to reach the end of the test a little quicker and thus invoke fullReset a little faster. After the user presses the already have account button they arrive at the welcome page. Because the fullReset is not doing the app reinstall for some unknown reason, the app remains in this state hence the second test fails.
It feels as though fullReset is mysteriously behaving like noReset, and I cannot quite point my finger on as to why.
@Tony_Skinner As per my knowledge end of scenario is not the end of test case, if you execute all the scenarios (or end of one feature file) then its called as end of test case and it’ll execute fullReset capability. is it the same behaviour in your master branch ?
@Tony_Skinner investigate by adding logs when you start and quit driver in your code.
check that during 1,2,3… tests you really do start driver and do quit driver.
Thanks Ravi. Yes I have the same implementation with the same 2 tests in the master branch, which is why I’m scratching my head 
I’ll get on that later once the kids are asleep
Hello,
Sorry for the late reply. It’s taken a while to revisit this owing to the current circumstances of the world
After a bit of digging it looks as though the driver wasn’t getting stopped. I will need to dig into it further to see why that’s the case so I’ll close this for now and carry on with the dig when time permits.
Thank you very much for your help. Sometimes all you need is to just discuss and flesh things out with people
