blakewatters/gist:5621704

## gistfile1.txt
Sal_: because I am so beyond stumped on this one
[10:53am] Sal_: So for the past 2 years we have had RestKit "vendored" into our project
[10:54am] Sal_: last week we added it as a pod via the .10.3 podspec
[10:54am] Sal_: and all the sudden running the Unit Test target results in an assertion failure in NSManagedObject+ActiveRecord.m
[10:55am] blakewatters: what's the assertion
[10:55am] Sal_: so the assertion is
[10:55am] Sal_:  '[RKManagedObjectStore defaultObjectStore] cannot be nil'
[10:55am] Sal_: but here is where it get's weird...
[10:56am] Sal_: i can confirm with vigorous breakpoints and logs that right up until i run a fetch request, the defaultObjecStore is definitely NOT nil
[10:56am] blakewatters: you may have wound up with 2 copies of RK being linked in
[10:56am] blakewatters: one in the app target and one in the unit tests
[10:56am] Sal_: fffffffff
[10:57am] Sal_: ok so maybe i need to clean out Xcode derived data and such?
[10:57am] blakewatters: unit tests in Xcode are implemented as bundles that are injected into the host app in an application test scenario
[10:57am] blakewatters: no its probably just a podfile change, gist me your podfile
[10:57am] Sal_: sure 1 sec
[10:57am] blakewatters: you probably just need to make sure that the pods are not linked with your unit test target
[10:58am] Sal_: https://gist.github.com/SRandazzo/853d27fe07408bf4ec3c
[10:58am] blakewatters: not the restkit podspec, your app
[10:58am] blakewatters: 's podfile
[10:59am] Sal_: https://gist.github.com/SRandazzo/7080879b61d6dfa2cb7c
[11:01am] blakewatters: what's the name of your application target?
[11:01am] Sal_: PaperlessPost
[11:01am] blakewatters: try adding this: link_with 'PaperlessPost'
[11:02am] blakewatters: that will tell CocoaPods to link the Pods.a only with that target, rather than linking with all targets (the default)
[11:02am] Sal_: k gonna give that a shot
[11:03am] Sal_: actually looking at my test target's build phases
[11:03am] Sal_: and it is linking against libsPods.a
[11:03am] Sal_: is that bad?
[11:04am] Sal_: I feel like i remember adding that in order to be able to utilize pods in my tests
[11:05am] blakewatters: so there's a bit of a tension here with CocoaPods and unit tests
[11:05am] blakewatters: because unit tests are injected into the host app, they have access to all the symbols exported by the host app at run time
[11:05am] blakewatters: you don't need/want to copy the same libraries into your test target and the host app
[11:06am] blakewatters: because what happens is that you have 2 copies of the same symbol and its undefined which one will be used at run time
[11:06am] blakewatters: you literally have 2 copies of all the classes present in the address space
[11:06am] Sal_: which explains why suddenly things were appearing to be nil...
[11:06am] Sal_: jeez
[11:06am] Sal_: ok that's incredibly helpful to know
[11:07am] blakewatters: the problem is that you need some of the configuration from the Pods, particularly the linker flags and the header paths
[11:07am] blakewatters: so that when you #import libraries from the tests it doesn't fail
[11:07am] blakewatters: you may well be getting a console log message about duplicated symbols if you look through the output
[11:07am] blakewatters: IIRC Xcode throws noise about it in the logs
[11:08am] Sal_: face palm
[11:08am] Sal_: ok that explains everything
[11:08am] tyl left the chat room. (Read error: Connection reset by peer)
[11:08am] Sal_: and look at that, tests are up and running again...
[11:08am] tyl joined the chat room.
[11:09am] Sal_: wow well thanks for your help
[11:09am] blakewatters: what I've done in GateGuru is actually just manually configured the settings on my unit test target as necessary, referring to the header paths, etc. from the main target
[11:09am] blakewatters: its definitely a rough edge in CocoaPods at the moment
[11:09am] Sal_: ok yeah that makes a lot of sense
[11:09am] Sal_: I actually recalling having to manually configure the RestKit headers on the test target
[11:10am] blakewatters: you can switch to your app target and copy/paste the settings to clone them
[11:10am] blakewatters: its just a curveball case for cocoapods -- you want all of the settings but none of the code
[11:11am] Sal_: yeah, i had a similar issue with having to link some of the cocoa frameworks like ImageIO
[11:11am] Sal_: all makes sense now
[11:12am] Sal_: well thanks that makes a ton of sense now
[11:13am] blakewatters: np
	Sal_: because I am so beyond stumped on this one
	[10:53am] Sal_: So for the past 2 years we have had RestKit "vendored" into our project
	[10:54am] Sal_: last week we added it as a pod via the .10.3 podspec
	[10:54am] Sal_: and all the sudden running the Unit Test target results in an assertion failure in NSManagedObject+ActiveRecord.m
	[10:55am] blakewatters: what's the assertion
	[10:55am] Sal_: so the assertion is
	[10:55am] Sal_: '[RKManagedObjectStore defaultObjectStore] cannot be nil'
	[10:55am] Sal_: but here is where it get's weird...
	[10:56am] Sal_: i can confirm with vigorous breakpoints and logs that right up until i run a fetch request, the defaultObjecStore is definitely NOT nil
	[10:56am] blakewatters: you may have wound up with 2 copies of RK being linked in
	[10:56am] blakewatters: one in the app target and one in the unit tests
	[10:56am] Sal_: fffffffff
	[10:57am] Sal_: ok so maybe i need to clean out Xcode derived data and such?
	[10:57am] blakewatters: unit tests in Xcode are implemented as bundles that are injected into the host app in an application test scenario
	[10:57am] blakewatters: no its probably just a podfile change, gist me your podfile
	[10:57am] Sal_: sure 1 sec
	[10:57am] blakewatters: you probably just need to make sure that the pods are not linked with your unit test target
	[10:58am] Sal_: https://gist.github.com/SRandazzo/853d27fe07408bf4ec3c
	[10:58am] blakewatters: not the restkit podspec, your app
	[10:58am] blakewatters: 's podfile
	[10:59am] Sal_: https://gist.github.com/SRandazzo/7080879b61d6dfa2cb7c
	[11:01am] blakewatters: what's the name of your application target?
	[11:01am] Sal_: PaperlessPost
	[11:01am] blakewatters: try adding this: link_with 'PaperlessPost'
	[11:02am] blakewatters: that will tell CocoaPods to link the Pods.a only with that target, rather than linking with all targets (the default)
	[11:02am] Sal_: k gonna give that a shot
	[11:03am] Sal_: actually looking at my test target's build phases
	[11:03am] Sal_: and it is linking against libsPods.a
	[11:03am] Sal_: is that bad?
	[11:04am] Sal_: I feel like i remember adding that in order to be able to utilize pods in my tests
	[11:05am] blakewatters: so there's a bit of a tension here with CocoaPods and unit tests
	[11:05am] blakewatters: because unit tests are injected into the host app, they have access to all the symbols exported by the host app at run time
	[11:05am] blakewatters: you don't need/want to copy the same libraries into your test target and the host app
	[11:06am] blakewatters: because what happens is that you have 2 copies of the same symbol and its undefined which one will be used at run time
	[11:06am] blakewatters: you literally have 2 copies of all the classes present in the address space
	[11:06am] Sal_: which explains why suddenly things were appearing to be nil...
	[11:06am] Sal_: jeez
	[11:06am] Sal_: ok that's incredibly helpful to know
	[11:07am] blakewatters: the problem is that you need some of the configuration from the Pods, particularly the linker flags and the header paths
	[11:07am] blakewatters: so that when you #import libraries from the tests it doesn't fail
	[11:07am] blakewatters: you may well be getting a console log message about duplicated symbols if you look through the output
	[11:07am] blakewatters: IIRC Xcode throws noise about it in the logs
	[11:08am] Sal_: face palm
	[11:08am] Sal_: ok that explains everything
	[11:08am] tyl left the chat room. (Read error: Connection reset by peer)
	[11:08am] Sal_: and look at that, tests are up and running again...
	[11:08am] tyl joined the chat room.
	[11:09am] Sal_: wow well thanks for your help
	[11:09am] blakewatters: what I've done in GateGuru is actually just manually configured the settings on my unit test target as necessary, referring to the header paths, etc. from the main target
	[11:09am] blakewatters: its definitely a rough edge in CocoaPods at the moment
	[11:09am] Sal_: ok yeah that makes a lot of sense
	[11:09am] Sal_: I actually recalling having to manually configure the RestKit headers on the test target
	[11:10am] blakewatters: you can switch to your app target and copy/paste the settings to clone them
	[11:10am] blakewatters: its just a curveball case for cocoapods -- you want all of the settings but none of the code
	[11:11am] Sal_: yeah, i had a similar issue with having to link some of the cocoa frameworks like ImageIO
	[11:11am] Sal_: all makes sense now
	[11:12am] Sal_: well thanks that makes a ton of sense now
	[11:13am] blakewatters: np