-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run on hardware iOS device #95
Comments
There are several challenges we need to overcome before we can achieve this. |
Here is how we achieved this recently.
And now, about the problems. After setting these all up, the app was running, it connected to the server, the tests started to run. And each of them failed. :| During investigating what could be wrong, it suddenly started to work. Without any code change. The same pattern repeated on one of my colleague's machine. (It failed the tests first, then it passed them half an hour later.) |
@simonracz did you run a react-native app? in debug mode ? Loading the bundle from the debug node server may take time, and detox may reach the default timeout and fail. |
If you mean the Mocha runner time out, then no, it wasn't that. We tried both release and debug mode. It was the demo-react-native sample. No modifications were made to it, apart from the project file modifications mentioned above. The first test line is "await expect(element(by.id('welcome'))).toBeVisible();". This failed with an Earlgrey assertion. It found the view with the id welcome, however it failed the visibility test. I started to debug the runtime view hierarchy. For example, I stopped the process and called "po [GREYElementHierarchy hierarchyStringForAllUIWindows]". For this view it showed the AX.id correctly, but the AX.frame was (0,0),(0,0). Sadly, I don't have saved logs. After it started to work, the AX.frame was correct. I wasn't able to reproduce it since then. |
I was able to reproduce this "Earlgrey fails the visibility test" issue. In fact I spent half-a-day on chasing this. I was able to narrow it down to the following. The matched view is rejected, because it's So, this shouldn't happen unless someone manually touches the I restarted, cleared, rebuilt, killed everything. Nothing helped. I don't think this is a Detox issue. I wrote it down only that in case you encounter it, let's share our findings. |
After spending more than a day on this bug I found the issue. Since some iOS version (don't know yet exactly when, but 10.3.2 and 10.3.3 are affected) Apple introduced a bug/feature around accessibility. The accessibilityFrame is not set, nothing isAccessible etc. unless the user is really using some accessibility features, e.g. voiceover. Earlgrey heavily depends on accessibility. I don't know why haven't anyone else found this, opened a bug about it yet. I'll open a bug report on Earlgrey and also open radar. I want to determine first the exact iOS version when this was introduced. |
@simonracz |
Made a radar about it. http://www.openradar.me/radar?id=5043342748418048 |
@simonracz |
I have found a way to force accessibility. |
@LeoNatan is it possible to run on real device now ? I couldn't find any docs on it |
@LeoNatan This will be so helpful to have! Thanks for putting in the work. Can't wait to get my hands on it. |
Running on devices is not supported yet. |
@pachun Please do not unassign members of the team from issues. Leave the issue management to us. Thanks. |
@LeoNatan I have no idea how that happened. Sincerest apology. 100% unintentional. All I meant to do was thank you. |
Cheers! |
@LeoNatan, are there any updates on the iOS real devices support? We are really looking forward to this functionality... |
Nothing to announce yet. It’s in our backlog and we intend to investigate this eventually, but it’s not on the top of our priorities. There are some challenges that we haven’t solved yet. |
Really looking forward of this too. My app need turn on the real device to check the camera. |
@LeoNatan Don't you think the following note in README should be adapted then?
IMO, it is a bit misleading. I would mention it is not yet supported on iOS. |
@fdnhkj I think you are right, could you go ahead and make a PR? |
@DanielMSchmidt Sure I can! Do you know if running on physical device on Android works? I have seen I'll adapt the README accordingly. |
AFAIK it should
Fidan Hakaj <notifications@github.com> schrieb am Mo., 8. Jan. 2018 um
15:49 Uhr:
… @DanielMSchmidt <https://github.com/danielmschmidt> Sure I can!
Do you know if running on physical device on Android works? I have seen
android.attached config in the docs
<https://github.com/wix/detox/blob/master/docs/Introduction.Android.md#4-add-android-configuration>
but I didn't test it so I'm not sure.
I'll adapt the README accordingly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#95 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABRm1t2L4xtCOM1DmKekI5Qa5isrXHd0ks5tIisBgaJpZM4MVY2O>
.
|
@LeoNatan these are indeed similar constraints to what Essentially the constraints about going through a
If the detox lib is part of the App bundle, then you are able to dynamically link it, even using preloads like The regular use-case here is splitting up an application into a smaller main executable that is loaded on launch and then other dylibs for features within an application. This is used to improve launch time so that that only the main dylib needs to be loaded when the app is launched and additional features can be linked only when they are needed. |
@lawrencelomax We decided to go that route to ease the setup and potential deployment issues of our users. They don't change their project and the system automagically adds the required Detox code in runtime. Once we are able to sign applications with Detox for running on device (in order to add the Detox dylib inside the bundle), it will be trivial to modify the signed entitlements to allow debugger attach. |
hey @LeoNatan I was wondering, how big are changes which you are trying to save users from in this
scenario? There's amazing xcodeproj project which lets you do pretty much anything you want with xcode project. So is there another problem on they way if we can implement a solution which manipulates over user's project in the cloud w/o bothering a user to configure detox manually and then maintain parallel versions of the app (with and w/o detox libs). update
*or actually before uploading to the cloud |
@maxkomarychev Yes, I am familiar with that project, thank you. We used to use xcodeproj before settling to the current system. In some ways, it was terrible (not xcodeproj, but our previous solution). Detox would make a change in the user's project; since a lot of our users are ... "Xcode challenged" (to be as politically correct as I possibly can in this late hour), they would not understand the changes, and revert some or make changes of their own. We used to have problems with people complaining about changes. Changes done using xcodeproj were hard to change if we wanted to make a change in Detox. Big mess. We won't be going back to that system, sorry. In your cloud proposed method, signing would still be an issue. We could sign it with an internal certificate, but that cannot guarantee a 100% functioning app (for example, is an app uses iOS extensions, using application groups and accessing files in the group container, etc.). Also, since Detox does not have a centralized backend, every user that would like to run Detox on a device would require them setting up this cloud on their own. I find it easier to just do everything locally (including signing with their own certificate). |
Is there any work happening on this one? |
No work, sorry. |
Is this happening in open source or is it more of an internal wix effort? |
Detox is an open source project, so the changes will be available once ready. |
Hi, How is this feature going? Do you have any updates? Thanks |
This is not a priority for us. No updates right now. |
But it is part of the roadmap https://github.com/wix/Detox/blob/master/docs/More.Roadmap.md#ios-physical-device-support is there any plan to make it available at some point? Thx |
Referencing @LeoNatan's answer #95 (comment) This is not a priority for us as we still see Simulators as a good enough tool for our testing. The Detox iOS rewrite will make this potentially easier to support, but we'll still need to put some effort into it as a separate task once the rewrite is done. |
The roadmap document isn't really maintained. As part of the rewrite, we need to go over documents and remove some of the more esoteric ones which we don't actively maintain (such as the roadmap one). |
With the pending rewrite, some of the more peculiar deployment issues should be solved (no need for |
@LeoNatan Is not clear for me if till today is possible or not to run on real devices from documentation https://github.com/wix/Detox/blob/master/docs/APIRef.Configuration.md I'm not seeing how to do it |
Well, clearly it is not possible, as evident by the discussion here. |
thanks! just want to be sure . Is something that would be possible to provide soon? @LeoNatan |
Not currently planned, as stated many times before. We are working on overhauling Detox’ internals for iOS, which will make it easier. |
I see the discussion kind of repeat itself, but still, 7 months since last reply, are there any plans on supporting ios physical device in the near future? |
Not in the very near future, but we keep this thread open for a reason. We are moving the pieces slowly toward that goal. |
No. Running on iOS hardware will take a lot more work. |
There is no need to ask about this every few months or after every release. The issue is open, and we haven't forgotten about it. Once the work has been done and we are ready to add this support, we will surely write about it here in the issue, as well as in the release notes. Thanks |
No description provided.
The text was updated successfully, but these errors were encountered: