Should FBDeviceControl work out of the box? about idb HOT 3 CLOSED

Thanks for the detailed write up. We wanted to get FBDeviceControl in an early stage so we could get more eyes on it and work on a general solution, rather than obscure the existence of it in XCTestBootstrap.

[DTXMessage alloc] returns nil. It seems the class is not fully loaded at runtime. Had to replace with [NSClassFromString(@"DTXMessage") alloc].

This must have slipped through when we switched from hard to weak linking. NSClassFromString is the correct way of doing this, so a PR would be appreciated :)

Path to XCTest.framework and IDEBundleInjection.framework are not provided or dynamically determined, and so when the data package is copied over to the device, those frameworks are not included (and thus the test runner app will crash due to not being able to find them).

I'll defer to @marekcirkos on this one, who is responsible for the bulk of FBDeviceControl. If you have a solution to this, please put up a PR.

No CodeSignProvider is ever provided to the bundles that are copied to the device. Therefore, even if I supply a valid path to the private frameworks to copy to the device, the executables can not be run as they are not signed appropriately.

This is currently by design. For obvious reasons we don't check-in certificates or any keys, it's up to the end-user to set this up. When we expose this through the CLI we can pick a reasonable default (where appropriate) or provide a way of inferring this from the Application, or explicit argument passing. We're always going to need a signing identity so this is just a matter of making it as convenient as possible.

I had assumed that this project was already working internally for you guys, but given these three obstacles I have to conclude that either some special setup is required (if so, it would be great to detail in the README), or that the open source project isn't intended to be fully functional out of the box?

We'll put this up a README detailing the experimental nature of the project at this stage. It isn't (currently) a full complement to FBSimulatorControl, but in time we hope that it can fulfill a similar purpose.

from idb.

Thank you for checking it out.
I am pretty sure I already fixed 1).

According to 2) 3). FBDeviceTestPreparationStrategy assumes that you have already prepared and signed:

1. test bundle you want to execute,
2. application used to launch test,
3. application data bundle with IDEBundleInjection.framework, XCTest.frameworkand test bundle properly structured.

This way you lose much less time waiting for test preparation and is much more robust as code signing on the fly gets tricky. We plan to opensource separate strategy or script that can do all of this for you and then properly document everything related to FBDeviceControl.

from idb.

Closing due to inactivity.

from idb.