Currently I'm writing all the Test Case actions in one javascript file, and using Xcode Instruments automation.traceTemplate file for executing the Test Case.
Following are contents from TestCase file.
var target = UIATarget.localTarget();
var app = target.frontMostApp();
var window = app.mainWindow();
//target.logElementTree();
target.delay(2);
UIATarget.localTarget().captureScreenWithName("Application launched");
target.frontMostApp().mainWindow().textFields()[0].setValue("demo");
target.delay(2);
UIATarget.localTarget().captureScreenWithName("Username entered");
var passwordfield = target.frontMostApp().mainWindow().secureTextFields()[0];
passwordfield.setValue("demo");
My Requirement:
I want to perform one action at a time on iOS device using Xcode Instruments instead of passing complete Test Case file as a input similar to implementation of Appium tool.
Thanks in advance..........
XCode instruments natively do not support on the fly Javascript. You have to have all your javascript in one file and execute all of the script at once. You are not able to stop execution, have separate test cases etc.
This is where appium comes into play, it will allow arbitrary JS execution. You create your test cases in the appium/selenium format and they would send commands to instruments in the background.
Run through this tutorial http://appium.io/slate/en/tutorial/ios.html?java#native-ios-automation and you don't even have to use JS, you can use Java/Ruby and you will be in a better shape.
Check out appiumRepl
You can send commands one-by-one and watch them happen on the device/emulator in realtime :)
There's a Ruby REPL as well.
Related
I am working on automating an Android app. We have a screen that has a table wherein the cell values keep on changing in seconds. I have observed that it takes more than a minute for AndroidDriver to execute a single action.
I have read on some other forums about this and got to know that this is how the UiAutomator2 works and it has nothing to do with Appium. UiAutomator2 waits for elements to come to a static state and then performs the actions.
Since the dynamic elements on the screen are unavoidable, is there any workaround for this to make Appium scripts execute with good speed? Let me know what you all think of this. I will really appreciate your comments on this. Thanks.
Yes, that is right. It has nothing to do with Appium itself, but with UiAutomator. UiAutomator takes accessibility snapshots only when the application is in idle mode and the framework itself is not optimized for cases when there are constant changes in the page view. As a workaround, try to play around with waitForIdleTimeout such as setting it to zero or try with setting the disableWindowAnimation to true in the desired capabilities.
You could also try with running the following commands:
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0
As a last resort, you could ask for the developers to provide you with a special build that has the animations removed in the source code.
I had the same issue, my specific problem was that the mobile app had a timer in the UI, that was changing its value every second.
Looks like the driver was waiting for the DOM to become idle, so it was SUPER slow because of that.
This simple command fixed the issue for me:
# Python code
driver.update_settings({"waitForIdleTimeout": 0})
Additional references:
https://appium.io/docs/en/commands/session/settings/update-settings/
https://github.com/appium/appium/issues/14155
While executing runAppInBackground() for Android application through Appium the app gets restarted but when executed the same manually couldn't be able to reproduce the same. I Would like to deep dive into implementation of a runAppInBackground() method to reproduce the same issue in a manual way.
You need to look behind the code of runAppInBackground
From java client side (your test code) perspective, it is a single call to Appium server:
POST "/session/:sessionId/appium/app/background"
If you continue looking into where its implemented on server side, you finish with appium-android-driver function.
In short what it does:
Get current activity and package
Press physical Home button
Wait for time you provided as argument (seconds)
Bring up back in focus based on different conditions; from the code you can understand what activity is being started
Basically its a sequence of adb shell commands, that you can run from terminal.
My guess is that step 4 you did manually may differ from what Appium is doing: different activities/arguments for activity been called
I am required to create iOS unit tests, where i need to push an sql .db into app location/sandbox/whatever (may be from testsuit's setUp() func) and run some CRUD operations from the testcases and later delete the db from tearDown() when tests done. How can i push a .db into app location for test, which will be used just like a db used inside app.
Another question, I need to run automated tests, so is there any command (like in Android we use adb, in Tize we use gdb) for iOS app to insert these database file in app location to run those testcases. If i am missing any point please help.
What is the standard way to test CRUD operations in a simulated db for iOS.
As far as my study, there is no adb/sdb like tool for iOS. Moreover there is an workaround for performing test on real database.
Steps
Keep the test-database into App/resource folder. You can skip this large test-database from your release build by following these technique.
Make a function in App side to replaceWithTestDatabase(), which basically replace your App database with App/resource/test-database. You can temporary copy current App db if you need.
If you want to access from AppTests (unit test), you can simply call Aapp/replaceWithTestDatabase as iOS Tests are hosted under main App.
If you want to access from AppUITests, you need to send extra launch argument from setUp() method to let App know that it should call replaceWithTestDatabase from app delegates. Here is a nice explanation how we can send arguments to main App from AppUITests.
Hope it helps.
We are trying to migrate from UIAutomation to XCUITests and did use the captureScreenWithName() API to programmatically generate screen shots.
What is the replacement in the XCUITests ?
(I know that automatically screenshots are taken in case of error, but we have a special test which runs forever in a loop and evaluates QA click,tap commands via network similar to the appium-xcuitest-driver https://github.com/appium/appium-xcuitest-driver)
Do I need to rip out private headers (XCAXClient_iOS.h) like the appium guys did in order to get a screenshot API?
Edit
I used the actual code line for the accepted solution from
https://github.com/fastlane/fastlane/blob/master/snapshot/lib/assets/SnapshotHelper.swift and its just this for IOS
XCUIDevice.sharedDevice().orientation = .Unknown
or in objC
[XCUIDevice sharedDevice].orientation =UIInterfaceOrientationUnknown;
I use a process on the host to lookup in the "Logs/Test/Attachments" directory all Screenshot_*.png files before the call , and find the new shot then after the call as the new file added in this directory.
Gestures (taps, swipes, scrolls...) cause screenshots, and screenshots are also often taken while locating elements or during assessing expectations.
Fastlane's snapshot tool uses a rotation to an unknown orientation to trigger a screenshot event (which has no effect on the app): https://github.com/fastlane/fastlane/tree/master/snapshot - you can use this if you want to be in control of some screenshots.
I need to automate a test on an IOS app using UI automation.
I need to test the following scenario.
1) open the mail app and select a file to share. This will open my app
2) Now I need to perform UI actions on my app and do some tests
I can't figure out how do automate this scenario using Instruments or Appium. All these tools take bundle name of one app. I need a way to control and perform UI actions on two app from a single script.
Any suggestions?
Edit: For clarification
This is not possible within one session
The solution is to split up your tests to encompass one or more webdriver sessions.
Part One:
desired_caps['app'] = 'sampleApp1'
driver = webdriver.new('http://0.0.0.0/wd/hub:4732', desired_caps)
// Do what you need to do.
driver.quit()
Part Two:
desired_caps['app'] = 'sampleApp2'
driver = webdriver.new('http://0.0.0.0/wd/hub:4732', desired_caps)
// Do what you need to do.
driver.quit()