Skip to content
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

Unable to integrate into iOS unit test target #41

Open
hhanesand opened this issue Nov 21, 2016 · 13 comments
Open

Unable to integrate into iOS unit test target #41

hhanesand opened this issue Nov 21, 2016 · 13 comments

Comments

@hhanesand
Copy link

hhanesand commented Nov 21, 2016

I've been struggling for a while to integrate the testing library into a unit test target, but I haven't found a solution that works yet.

Given a pod file like the following :

platform :ios, '10.0'

use_frameworks!

target 'tacx' do
    
    pod 'RZBluetooth/Mock'
    
    target 'tacxTests' do
        inherit! :search_paths
        pod 'RZBluetooth/Test'
    end

end

A unit testing file:

@import RZBluetooth;

@interface tacxTests : RZBSimulatedTestCase
@end

@implementation tacxTests
@end

Everything compiles just fine, but when running the test, it prints a message stating :

2016-11-20 19:05:59.112 tacx[95628:5961223] Failed to load test bundle from file:///Users/xxxxxxx/Library/Developer/Xcode/DerivedData/tacx-ghqgcpxbcphxnmhievkvngfndhzq/Build/Intermediates/CodeCoverage/Products/Debug-iphonesimulator/tacx.app/PlugIns/tacxTests.xctest/: Error Domain=NSCocoaErrorDomain Code=3588 "dlopen(/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/tacx-ghqgcpxbcphxnmhievkvngfndhzq/Build/Intermediates/CodeCoverage/Products/Debug-iphonesimulator/tacx.app/PlugIns/tacxTests.xctest/tacxTests, 265): Symbol not found: OBJC_CLASS$_RZBSimulatedTestCase
Referenced from: /Users/xxxxxxx/Library/Developer/Xcode/DerivedData/tacx-ghqgcpxbcphxnmhievkvngfndhzq/Build/Intermediates/CodeCoverage/Products/Debug-iphonesimulator/tacx.app/PlugIns/tacxTests.xctest/tacxTests
Expected in: /Users/xxxxxxx/Library/Developer/CoreSimulator/Devices/D4A4BA5A-3023-4B18-B912-EE1FCDA1835D/data/Containers/Bundle/Application/2060D194-B119-4FEA-A8B1-917686855AB4/tacx.app/Frameworks/RZBluetooth.framework/RZBluetooth
in

As you can see by the Referenced from and Expected in lines, Xcode sees a symbol from the RZBluetooth framework (_OBJC_CLASS_$_RZBSimulatedTestCase) and expects it to be located in /tacx.app/Frameworks/RZBluetooth.framework/RZBluetooth, which is the app's version of RZBluetooth (created by pod 'RZBluetooth/Mock' in the podfile). This causes the app to crash because it can not find a the symbols for RZBSimulatedTestCase.

Are you aware of any way to explicitly importing the unit test's version of the library? (that is the version of the library that contains the RZBSimulatedTestCaseclass?

@hhanesand
Copy link
Author

hhanesand commented Nov 21, 2016

I guess UI tests can perform a similar purpose, since you can control when you want to launch the app.

UI tests can't access application files - back to square one?

@KingOfBrian
Copy link
Contributor

Yea, UI Tests can't drive the mocks at this point. I'm not sure why you're encountering the errors you are, seems more like a Cocoapods issue. I wasn't using the nested layout above, but called it out more explicitly

target "MySDK" do
    pod "RZBluetooth"
    pod "RZBluetooth/Mock"
end

target "MySDKTests" do
    pod "RZBluetooth/Test"
end

@hhanesand
Copy link
Author

hhanesand commented Nov 22, 2016

Hmmm, strange, I get the exact same error with that pod file. What version of cocoapods are you using and does it compile/run correctly on your side?

Also what are your have 'Host Application' and 'Allow testing Host Application APIs' set to in the test target?

@KingOfBrian
Copy link
Contributor

I've usually done Host Application. I also noticed there's an issue with the Pod and RZBTestDefines.h not being included.

If this is blocking you, RZBSimulatedTestCase doesn't really do much. You can copy the setUp and tearDown methods and you should be fine, asuming the Mocks are being included correctly. I'm working to resolve the issues now, but it may take a few.

@KingOfBrian
Copy link
Contributor

Hey @hhanesand , I updated the pod spec, can you give it another shot? It looks like there were a few issues that should be resolved.

@KingOfBrian
Copy link
Contributor

Hey @hhanesand -- I'm going to close this issue, re-open if you're still having a problem.

@joshuatbrown
Copy link

I'm updating a project right now from CocoaPods 1.0.1 to 1.5.3 and seeing the same error message in the console that @hhanesand originally posted here. @KingOfBrian My Podfile looks a lot like the one you posted (though it's a bit more complex). Do you have any thoughts on why this might still be happening, even though you updated the podspec?

@KingOfBrian
Copy link
Contributor

@joshuatbrown are you sure the target isn't a UI Test? Are the Unit Tests "Hosted"? If you can post a podfile with names stripped out that might help figure out what's going on.

@joshuatbrown
Copy link

@KingOfBrian Wow — thanks for the quick response. It's not a UI Test target, and I don't think the unit tests are "Hosted". The project is an iOS Framework, and the Podfile looks something like this:

source "https://github.com/CocoaPods/Specs.git"

source "<redacted-internal-source>"

# Defines a global platform for your project
platform :ios, '10.0'

# Uncomment this line if you're using Swift
use_frameworks!

pod "<redacted-internal-framework>", :git => <redacted>", :branch => "<redacted>"

pod 'RZBluetooth',      '~> 1.2'
pod 'RZBluetooth/Mock', '~> 1.2'

target '<redacted>' do
end

target '<redacted>Tests' do
    pod 'RZBluetooth/Test', '~> 1.2'
end

I've also tried including the pods inside of the main target (called '<redacted>' here) and had the same results. I'm honestly not sure why that target is empty, but it seemed to work on CocoaPods 1.0.1, so I guess CocoaPods just assumes the pods listed above apply to that target.

@joshuatbrown
Copy link

I was able to reproduce this with a sample project. It's here: https://github.com/joshuatbrown/RZBCocoaPods

@KingOfBrian
Copy link
Contributor

Thanks @joshuatbrown -- that's helpful! Unfortunately it looks like the Test sub-pod doesn't work correctly. It should really be generating it's own Framework that depends on RZBluetooth/Mock (Which should also be it's own framework). What's happening here, is when the test bundle is built, the RZBluetooth from the non-test-target is getting copied into the bundle and over-writing the RZBluetooth.framework with the Test sub-pod. I was able to get the tests to run by adding 'RZBluetooth/Test' to the main-target, but obviously that's not a good solution.

I'm not able to generate a fix for this at this time unfortunately. To get your tests working, I recommend just copying RZBSimulatedTestCase and the helpers into your test target. That should un-block you in a reasonably clean way.

I'm going to re-open this, and would appreciate help with a fix if you're interested in diving into the Podfile.

Brian

@KingOfBrian KingOfBrian reopened this Aug 1, 2018
@joshuatbrown
Copy link

joshuatbrown commented Aug 2, 2018

@KingOfBrian I may be able to help. Can you tell me more about what you mean by "diving into the Podfile"? I'm guessing you mean the RZBluetooth.podspec, but can you explain at least at a high level what changes you expect this needs? I'm happy to tweak the subspecs and see if I can get it working but don't have much of an idea of where to start.

@mplorentz
Copy link
Contributor

I did some more digging and found an issue for this in CocoaPods. It was reported in CocoaPods 1.3.1, and seems unlikely that it will be fixed anytime soon.

The latest word from the CocoaPods maintainers is that this is "outside the scope of subspec capabilities" and they recommend creating a separate Podspec for it.

@KingOfBrian are you open to having a separate Podspec instead of a subspec for RZBluetooth/Test?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants