I'm using appium to automate some tests but I want the application under test to return to the same start in between tests. I think that the easiest way to do this would be to close and reopen the app. Is this possible with appium? If so, how?
(Note: driver.close() does not work)
You can do this with driver.quit(). You will need to reconnect but as long as the server is launched with the --no-reset switch it should boot up in the state where you left it.
You could also background the app as an alternative using executeScript with "mobile: background" (see https://github.com/mutualmobile/appium/commit/53f0c58857eec512f48732d40ace71b7db4ae32f) or calling the UIAutomation command directly with executeScript. (e.g. au.background(5)) for 5 seconds in the background.
Related
I have two drivers, one for my app and one for Chrome.
The flow is like so:
Start the app driver, set up the app (app starts background process).
Start the Chrome driver, do some stuff there and quit this driver.
But what I actually want to do is this:
Start the app driver, set up the app (app starts background process).
Close this app, but leave the background process running
Start the Chrome driver, do some stuff there and quit this driver.
Open back up the app which I have closed in step 2
Quitting the driver (driver.quit()) is obviously not an option, since this also kills the background process. Same as with (driver.close_app()).
I was thinking about doing this via UI, by simply clicking the "Recent Button" and swiping up on my app, but how would I then get back the app?
My question: Is it possible to close the app without killing the background process, if so - how?
After asking in the Appium Forum the solution is as follows:
Put the app into background for an indefinite amount of time:
driver.background_app(-1)
and activate it once you need it again:
driver.activate_app("app.id")
I would like to run two applications from two XCode GUI instances on iPhone Simulator,
The two apps communicate with each other using socket and I would like to do step by step debugging in each app to debug the some logic internally.
I wish to use the debugger and do step by step in each XCode instance while the two apps are running on the iPhone simulator
The issue is that I can only use breakpoint\stop the run in one XCode instance while the other XCode\app seems to be running (the title in the target is "Running ..") but could not catch the breakpoint or even see any print\traces in the XCode debug console.
Any idea what could be the issue?
Thank you!
Ronen
I just tried debugging two apps simultaneously on the iOS simulator, and simple things seem to work correctly.
Remember that on iOS, apps that are not in the foreground are generally suspended unless they register background tasks. So only the foreground one is going to make any progress. But that's true regardless of whether you are in the debugger or not.
If one or the other apps has registered a background task, and that background task isn't getting any time when you have this scenario of two apps running under the debugger, please file a bug with an example of your scenario at http://bugreporter.apple.com.
But if you want to follow foreground processing in the two apps, you'll have to manually foreground the one you want to run as you are stepping along. But that's just a reflection of how apps run on iOS.
One of the benefits of Appium is that I can run tests against the app without compiling in any instrumentation. But, there's a feature I want to turn off in my app when Appium is the user.
How can Appium can send information directly to the app, to tell it that Appium is driving? This needs to happen shortly after launch, so hiding a secret switch somewhere is not a good option.
You can use the processArguments capability to pass application launch arguments through Appium to your application. Inside your application you can read the launch arguments and values using NSUserDefaults.
is there any way to remove app from background using Appium in Windows.
What i want is
- Start server with -No reset
-Run the program
-Program ends
-driver quits using driver.quit() method
Now when i start my test execution again , the app on which i was earlier working is there in the memory.So i have to press "Home" key and remove it from memory and then start working on it. (e.g. if i am working on messaging app of device , after test execution i press "Home" hardkey and manually remove the app as follows)
Please help me how to do this
You have to use driver.closeApp() before driver.quit().
Please see this link with the different appium methods provide app control.
How can one test the scenario of Application Launch in background for handling Background NSURLSession's event?
Flow:
Application starts a upload/download task using Background URL
session.
User hits home button. App is in suspended or in background
state.
OS decides to Exit the application. I know, one can exit the app by double-tapping home button and swipe-up the particular app. But in that case OS will never re-launch the app in background for event handling.
Upload/download task needs some event handling. OS re-lauches App in background.
So the question is how do I make OS exit the app like it may normally do after some-time. The purpose is to test the code for this scenario. I tried using UIApplicationExitsOnSuspend but it does not work since then App can not be launched in Background.
It's not a perfect solution, but I was able to manually test the launch of an app due to a Background URLSession on a physical device as follows:
Connect device for debugging via USB
Disable Internet connectivity on device (i.e. disable WiFi/Cellular)
Start the app via Xcode
Issue a request using background URLSession. The request shouldn't fail, it will just be waiting around for an Internet connection until it times out, so use a reasonably long timeout to make testing easier.
Kill the app via Xcode (press stop button)
View the device logs via Windows > Devices and Simulators
Enable Internet connectivity on the device again without starting the app
The requests from the background URLSession should then complete and in the device logs (from step 6.) you should see any NSLog statements issued as a result of the app being launched via the application(_:handleEventsForBackgroundURLSession:completionHandler:) app delegate method.
They key point is that killing the app via Xcode, as opposed to killing it using device itself, does not prevent the app from being relaunched for background event handling.
A possible alternative to killing the app manually via Xcode might be to intentionally crash the app in code - this might be more suitable for automated testing.
You could write an app that has a button that allocates and intentionally leaks chunks of memory. If you get this thing to allocate enough RAM, the OS will start killing other apps to get their RAM back.
Hopefully this would exhibit the behavior you need.