> On 13 Jul 2015, at 22:58, Roland King <[email protected]> wrote: > >> >> On 14 Jul 2015, at 12:28, Joar Wingfors <[email protected]> wrote: >> >> Hi Roland, >> >> With the information currently provided I cannot say what’s wrong with your >> current setup. If you can attach your project to a bug report and send it to >> us I imagine we could quickly identify why it isn’t working. >> >> If you’d rather try to just get things working on your own I’d advice you to >> create a new unit test target in the same project and see if you have better >> luck with that. Initially just try to run the stub test method as you get it >> from the template. As a second step, have the test target link your >> framework and call some API from your test method. Taking one step at a time >> like this should allow you to pinpoint where things are working, and what >> makes them no longer work. >> >> You should absolutely be able to test frameworks, and as long as your >> destination is OS X or the iOS simulator you don’t need an application to >> host them. >> >> If you were to file a bug report, I’d also be interested in which version of >> OS X, iOS and Xcode you’re using. >> >> Thanks, >> >> Joar >> > > Thanks - knowing it’s supposed to work sent me back for another try. > > As I guessed there was a load issue loading the test bundle, but it wasn’t a > problem loading the embedded library (which was my first thought), it was > CoreBluetooth, which the second library happens to use. At the end of the > build all the ‘swift standard libraries’ are copied into the Frameworks > directory for an executable, or in this case a test bundle. That includes > libswiftCoreData, libswiftCoreGraphics, all sorts of stuff I’m not using, > however it does’t (on OSX only as far as I can tell) copy in > libswiftCoreBluetooth *unless* the app or the test cases themselves > explicitly import CoreBluetooth, then it does. Adding an unused import of > CoreBluetooth at the top of the test case source was enough to get that > copied into the test bundle and then it works as far as I can tell. > > Would have been helpful if there was some more verbose logging of the bundle > load failing during the test process, I expect somewhere a message like > “unable to find @rpath/libswiftCoreBluetooth.dylib” got swallowed up, unless > there’s another log file I haven’t found.
I’m not set up to verify at this very moment, but I believe that Xcode 7 offers more verbose logging of this type of dyld failures during testing. Joar _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
