Let's imagine that I have 2 iPhones (or iPads) connected to my Mac and I have to automate a test calling the lldb and loading an app from the COMMAND LINE, not XCODE; so how can I specify which device it should use? Maybe some kind of extra param when calling platform select remote-ios?
lldb does not know how to load apps onto an iOS device, or to start up connections to the debug agent on an iOS device. That bit is done by Xcode, and then the connections are handed off to lldb. Xcode has a fair bit of support for automating test cases for iOS debugging. That's the only supported way to do this at present.
Related
Goal:
Connect iOS device (physical device) to macbook
Use Appium / IntelliJ / or any other software to capture app errors from the device
I run automation tests using simulated devices, however, it's proving to not be as affective as manual testing for I'm getting different results. What I want is to simply connect my device to my macbook, run something to log app errors as I interact with my test device.
My current set up to run automated tests:
Appium
IntelliJ - Using simulated devices (No longer wanting to do)
To view what's going on in the device, you'll need to use Xcode. The easiest way to obtain that is to use the Mac App Store application.
If you're able to build your app there is a lot more debugging you can do, but I'm assuming you're not able to do that based on what you've written and won't provide instruction on that.
Attach device
Launch Xcode
Click Window menu
Click Devices and Simulators
Unlock device
Click Open Console if you're looking to see live activity of the system (this is very noisy and unlikely to be of much use) or View Device Logs to see any crash reports.
I managed to control my android device with both 'ADB' and 'Appium' on windows system.
Question is : Can I do the same for iPhone ? as i heard that it can't be done in windows platform and it isn't clear on net.
Also wanted to know if the iPhone sdk having tools like ADB 'command line tool' to do some things like make phone call , or press , or swipe ..
I trigger all of that with python scripts.
Thanks
For iPhone automation testing with the help of appium, you must need Mac machine.For iOS app testing using appium, the primary requirement is XCode which comes with only iOS Operating System which you can get only on MacBook/MacMini.
There is no tool like ADB for iOS. Whatever command you want to send to the device, all those needs to be sent through appium driver only. You can check the appium driver, there are lot of in built methods like hiding keyboard or launching app or opening notifications panel etc.
When I'm running the Apple Watch simulator from Xcode, both the iOS simulator and the Watch Simulator launch but the iOS app doesn't start up. Is that by design or am I doing something wrong? I can launch either in the simulators and they communicate as expected but if both would launch at the same time that would be very useful.
Xcode doesn't have an option to automatically run both apps for you.
The existing approach is historically by design, but there are other reasons for it too. For example:
It's faster, and uses less resources to not unnecessarily (build, install and) launch the host app.
You may want to test that the watch app works as expected when it can't communicate with its paired device or app.
Within Xcode, you tell it to run a particular app, whether it be the iOS app or the watchOS app. That's the (only) app that launches.
The best you can do (within Xcode) is to first run the iOS app, then run the watchOS app. Both will be running, and you can then debug either one from within Xcode.
Of course, you could always submit a feature request to add an option to launch both apps.
The iOS simulador that installs with Xcode is a VM or a emulator like Android does?
It's neither a Virtual Machine nor an Emulator. It's a simulator, in another words it's a standard mac application which mimic the behaviour of iOS devices. It mimics most of the features of an actual devices, but lacks some major features. So you need to use a real device for testing some of the real world scenarios.
You can read more about simulators here : About Simulator
I would like to quote some key information from the above linked page:
What is Simulator
Simulator allows you to rapidly prototype and test builds of your app
during the development process. Installed as part of the Xcode tools,
Simulator runs on your Mac and behaves like a standard Mac app while
simulating an iPhone, iPad, Apple Watch, or Apple TV environment.
Think of the simulator as a preliminary testing tool to use before
testing your app on an actual device.
Need of actual device for Testing
Simulator is a useful tool, but it should not be the only way you test
an app. Because the simulator is an app running on a Mac, it has
access to the computer’s resources, including the CPU, memory, and
network connection. All of these resources are likely to be faster
than those found on a mobile device. As a result, the simulator is not
an accurate test of an app’s performance, memory usage, and networking
speed. For this same reason, always test the performance of your app’s
user interface on a device. In Simulator, your app’s user interface
may appear to run both faster and smoother than on a device.
Also keep in mind that some user interface elements can be easier to
interact with in Simulator using a mouse than when trying to interact
with the app through touch on a device.
Finally, there are some hardware and API differences in Simulator.
These differences may affect your app when testing in Simulator.
Before execution of a Monkeytalk script, I am manually opening my iPhone app on the actual device. I want to launch and close my app using xcode command / Monkeytalk-pro command itself.
Is this possible?
MonkeyTalk works by hooking into your application. Since MonkeyTalk never actually overrides anything the operating system does, it can't do anything your app can't do. Which includes the app launching by itself, I'm afraid. That's life with Apple though, we'll never have anything as easy as those Android developers have.