quit() or terminate() simulate app killed from background?
Hodor4Me opened this issue · comments
Using framework to monitor / audit network requests of our app. At the moment, using terminate() which seems to work as expected, but I also noticed quit(). Looking at the comments in SBTUITestTunnelClientProtocol, terminate() looks to cleanly shutdown/disconnect the tunnel connection. So does that mean quit() will just abruptly abort the app? Which would simulate an actual swipe up on the app to kill it from the background? I want to make sure upon relaunch, using launchTunnel(), no requests will be cached.
Also I seem to remember (at least on our app) that after swiping up and killing an app from the background, users would sometimes have to wait a few seconds before relaunching the app to make sure all data caches were really cleared from the device's background. If this is the case, do I need to do any kind of thread sleep in my test after calling terminate() or quit() before launchTunnel() to ensure a truly clean launch?
You should use terminate to close the app and simulate the user quitting the app. We do this to test similar scenarios as those you described and never had to add any additional delay.
To sum up: you launchTunnel, change the state of your app, terminate, launchTunnel again and assert that the state of the app is the one you expected.
On the other side quit calls abort() which produces abnormal process termination. This could be called from tearDown() methods to make sure the app is really closed before the next test begins. This was needed as a workaround a few years ago but is no longer useful today.
@tcamin thanks for the clarifications. Curious for the cases where quit() would be used?
Were invoking quit() on tearDown() because empirically it was guaranteeing more stable test executions. Sometimes we observed that the previous test was still running when the next test was being launched. That being said we no longer use this workaround since a couple of Xcode majors.