Rightpoint / RZVinyl

Stack management, ActiveRecord utilities, and seamless importing for Core Data
Other
21 stars 6 forks source link

RZVinyl For unit Tests #64

Closed Rahul0106231 closed 8 years ago

Rahul0106231 commented 8 years ago

Im trying to write unit tests to a legacy code which was using RZVinyl for the core data .. For some reason after initialising the stack ,it becomes nil when accessed it again at a later point.. Anyone facing this issue ?

The static variable s_default stack either gets nil or is being created twice..

ZevEisenberg commented 8 years ago

@kingofbrian could this be your favorite double import bug?

mr-fixit commented 8 years ago

@Rahul0106231 Could you post the unit test you're writing?

KingOfBrian commented 8 years ago

Hey @Rahul0106231 , I'm guessing you have RZVinyl linked to your test target twice. This isn't an RZVinyl bug, but it's bitten me many times. Your app probably links with RZVinyl, and with the .xctest bundle probably also links with RZVinyl. This causes 2 versions of the static variables to get loaded into memory and has been known to make developers think they're insane.

This is caused by a cocoapods bug. I'm guessing that under Project->Info->Configurations, if you expand Debug, your Test target points to the same .xcconfig file as your main target. This .xcconfig file causes header includes of your main target pods (which you want) and linking with your main target pods (which causes madness).

The fix is to create a target in your Podfile for your test and make sure that it includes at least 1 pod. When you re-run pod install, it will generate a .xcconfig for your test target which will include your main target, but not link to it. They are often not added to your project, so right click the Pods group and add existing files. There should be Pods-TargetNameTests.configuration.xcconfig files. Add them to your project (but be sure not to add them to your target). Then go back to Project->Info->Configurations, and under your TargetNameTests target, select the new .xcconfig file.

Hope that helps, tell me how it goes.

Brian

Rahul0106231 commented 8 years ago

Wow u might be right here.Below is my stack over flow question with detailed description,

http://stackoverflow.com/questions/34267533/core-data-in-unit-tests-with-rzvinyl

Let me try on what you have suggested and get back to u.

Thanks for the help.

Regards, Rahul B

On Tue, Dec 15, 2015 at 8:21 PM, Brian King notifications@github.com wrote:

Hey @Rahul0106231 https://github.com/Rahul0106231 , I'm guessing you have RZVinyl linked to your test target twice. This isn't an RZVinyl bug, but it's bitten me many times. Your app probably links with RZVinyl, and with the .xctest bundle probably also links with RZVinyl. This causes 2 versions of the static variables to get loaded into memory and has been known to make developers think they're insane.

This is caused by a cocoapods bug. I'm guessing that under Project->Info->Configurations, if you expand Debug, your Test target points to the same .xcconfig file as your main target. This .xcconfig file causes header includes of your main target pods (which you want) and linking with your main target pods (which causes madness).

The fix is to create a target in your Podfile for your test and make sure that it includes at least 1 pod. When you re-run pod install, it will generate a .xcconfig for your test target which will include your main target, but not link to it. They are often not added to your project, so right click the Pods group and add existing files. There should be Pods-TargetNameTests.configuration.xcconfig files. Add them to your project (but be sure not to add them to your target). Then go back to Project->Info->Configurations, and under your TargetNameTests target, select the new .xcconfig file.

Hope that helps, tell me how it goes.

Brian

— Reply to this email directly or view it on GitHub https://github.com/Raizlabs/RZVinyl/issues/64#issuecomment-164786295.

Rahul0106231 commented 8 years ago

Unfortunately , it dint help .. i have made the changes to podfile as prescribed and ran the install again .. I have added the tests.xcconfig files to the project and changed the configuration, even then i can see that s_default stack becomes nil after being set ..

On Wed, Dec 16, 2015 at 1:54 AM, Rahul Balimidi rahul0106231@gmail.com wrote:

Wow u might be right here.Below is my stack over flow question with detailed description,

http://stackoverflow.com/questions/34267533/core-data-in-unit-tests-with-rzvinyl

Let me try on what you have suggested and get back to u.

Thanks for the help.

Regards, Rahul B

On Tue, Dec 15, 2015 at 8:21 PM, Brian King notifications@github.com wrote:

Hey @Rahul0106231 https://github.com/Rahul0106231 , I'm guessing you have RZVinyl linked to your test target twice. This isn't an RZVinyl bug, but it's bitten me many times. Your app probably links with RZVinyl, and with the .xctest bundle probably also links with RZVinyl. This causes 2 versions of the static variables to get loaded into memory and has been known to make developers think they're insane.

This is caused by a cocoapods bug. I'm guessing that under Project->Info->Configurations, if you expand Debug, your Test target points to the same .xcconfig file as your main target. This .xcconfig file causes header includes of your main target pods (which you want) and linking with your main target pods (which causes madness).

The fix is to create a target in your Podfile for your test and make sure that it includes at least 1 pod. When you re-run pod install, it will generate a .xcconfig for your test target which will include your main target, but not link to it. They are often not added to your project, so right click the Pods group and add existing files. There should be Pods-TargetNameTests.configuration.xcconfig files. Add them to your project (but be sure not to add them to your target). Then go back to Project->Info->Configurations, and under your TargetNameTests target, select the new .xcconfig file.

Hope that helps, tell me how it goes.

Brian

— Reply to this email directly or view it on GitHub https://github.com/Raizlabs/RZVinyl/issues/64#issuecomment-164786295.

Rahul0106231 commented 8 years ago

As of now as a workaround , when s_defaultstack == nil , instead of populating the stack with default values(i.e nil)..Im populating with my project model name details which is working for now(atleast solved the crash) .. But im afraid of it's side effects ..

Just to add a bit more info , im setting the stack in the unit tests target and accessing it in main app for processing the json and storing it to coredata ..and for some reason it becomes nil only once at the start of unit tests .. I was under the impression that one static variable is formed in the application scope and the other is from the unit tests target scope ..

Regards, Raahul.B

On Wed, Dec 16, 2015 at 5:56 PM, Rahul Balimidi rahul0106231@gmail.com wrote:

Unfortunately , it dint help .. i have made the changes to podfile as prescribed and ran the install again .. I have added the tests.xcconfig files to the project and changed the configuration, even then i can see that s_default stack becomes nil after being set ..

On Wed, Dec 16, 2015 at 1:54 AM, Rahul Balimidi rahul0106231@gmail.com wrote:

Wow u might be right here.Below is my stack over flow question with detailed description,

http://stackoverflow.com/questions/34267533/core-data-in-unit-tests-with-rzvinyl

Let me try on what you have suggested and get back to u.

Thanks for the help.

Regards, Rahul B

On Tue, Dec 15, 2015 at 8:21 PM, Brian King notifications@github.com wrote:

Hey @Rahul0106231 https://github.com/Rahul0106231 , I'm guessing you have RZVinyl linked to your test target twice. This isn't an RZVinyl bug, but it's bitten me many times. Your app probably links with RZVinyl, and with the .xctest bundle probably also links with RZVinyl. This causes 2 versions of the static variables to get loaded into memory and has been known to make developers think they're insane.

This is caused by a cocoapods bug. I'm guessing that under Project->Info->Configurations, if you expand Debug, your Test target points to the same .xcconfig file as your main target. This .xcconfig file causes header includes of your main target pods (which you want) and linking with your main target pods (which causes madness).

The fix is to create a target in your Podfile for your test and make sure that it includes at least 1 pod. When you re-run pod install, it will generate a .xcconfig for your test target which will include your main target, but not link to it. They are often not added to your project, so right click the Pods group and add existing files. There should be Pods-TargetNameTests.configuration.xcconfig files. Add them to your project (but be sure not to add them to your target). Then go back to Project->Info->Configurations, and under your TargetNameTests target, select the new .xcconfig file.

Hope that helps, tell me how it goes.

Brian

— Reply to this email directly or view it on GitHub https://github.com/Raizlabs/RZVinyl/issues/64#issuecomment-164786295.

KingOfBrian commented 8 years ago

Hey Rahul, I still would bet that the double-linking issue is your problem. Look at your build logs, and see if RZVinyl is linked with your test target. If it is, you are double linking. and will see the static var appear to nil out, but it's really 2 versions of the static variable.

The timing is probably associated with when the test bundle is loaded into the application. The first time you populate the static var, the test bundle hasn't been loaded. Then when the test bundle is loaded, the obj-c runtime points to new implementations of defaultStack / setDefaultStack: in your test bundle with fresh static variables. The next time you call default stack the variable will be nil, but you still have 2 copies in memory, which will be problematic.

Rahul0106231 commented 8 years ago

Yes, i think there are 2 copies (stacks) in memory created now .. I have printed the NSManaged Object Id's and could see 2 memory addresses for the same object .. I still dont understand how to solve this problem .. How to check if RZVinyl is linked twice ? Which logs should i be checking ?

On Wed, Dec 16, 2015 at 9:23 PM, Brian King notifications@github.com wrote:

Hey Rahul, I still would bet that the double-linking issue is your problem. Look at your build logs, and see if RZVinyl is linked with your test target. If it is, you are double linking. and will see the static var appear to nil out, but it's really 2 versions of the static variable.

The timing is probably associated with when the test bundle is loaded into the application. The first time you populate the static var, the test bundle hasn't been loaded. Then when the test bundle is loaded, the obj-c runtime points to new implementations of defaultStack / setDefaultStack: in your test bundle with fresh static variables. The next time you call default stack the variable will be nil, but you still have 2 copies in memory, which will be problematic.

— Reply to this email directly or view it on GitHub https://github.com/Raizlabs/RZVinyl/issues/64#issuecomment-165153078.

KingOfBrian commented 8 years ago

In the Report navigator, select the last build item before a test action. After all the .m files in your test target there should be a line Link /Path/To/....../TargetTests.

Rahul0106231 commented 8 years ago

raised an issue at cocoapods github page .. I tried all sorts of tricks i could get from stackoverflow but none of them worked .. Here;s my new stack overflow question and the git hub issue ..

http://stackoverflow.com/questions/34330538/cocoa-pods-with-unit-tests-issue https://github.com/CocoaPods/CocoaPods/issues/4671

Please let me know if somethig clicks you after looking at it..But yes,i believe the problem is double linking .. but i dont understand why is it happening ..

Cocoapods owner admitted that it is a known issue .. But im assuming there should be some work around coz it affects the unit tests a lot..

KingOfBrian commented 8 years ago

Hey Rahul, I'm going to close this as it's not an RZVinyl issue. If you're still stuck email me at brian.king@raizlabs.com I may be able to help further.