Add iOS unit tests, replace unit test dependencies with cocoapods, fix iOS build errors

[rhgills]

Lots of changes in this one.

Moved the unit test target out into a separate xcode project, which is included in a workspace, alongside a separate project for building the OS X static library. Added an iOS unit test target. Now using cocoapods to provide the OCHamcrest and OCMockito dependencies for the unit test targets. In addition, we use cocoapods to link the library into the unit tests, instead of manually compiling the necessary sources into the unit test bundle. Doing all this revealed a problem: isEqualTo: doesn't exist on iOS. This was easily fixed by changing isEqualTo: to isEqual:, which is present on both platforms. As near as I can gather isEqualTo: exists for use by components interfacing with applescript, so this shouldn't present a problem. See http://stackoverflow.com/questions/7096691/difference-between-isequalto-and-isequal and http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Protocols/NSComparisonMethods_Protocol/Reference/Reference.html.

There are four unit tests that are currently failing on iOS, but still passing on OS X. All are found in TyphoonTypeDescriptorTests. On iOS, instead of TyphoonPrimitiveTypeUnsignedLongLong we get TyphoonPrimitiveTypeInt and instead of TyphoonPrimitiveTypeLongLong we get TyphoonPrimitiveTypeLong.

Let me know your thoughts!

[jasperblues]

Thanks Robert!

[rhgills]

My pleasure!

[jasperblues]

One thing that is broken now is the Test Coverage reports. . . the CI build was producing these here: http://jasperblues.github.io/Typhoon/coverage/index.html

. . . I'm not sure if its possible to produce test coverage (*.gcda files) from a library. . .

[rhgills]

Apologies, I completely overlooked the entire ant build system when performing my own tests. I realized that last night and spent a while looking into it. Thanks for fixing the rest of the automated build! Coverage should also be fixed now.

I added a build.sh script (which just calls ant) to hopefully make it more obvious that, hey, there's a build system here. Not sure if that's at all helpful though - if you're going to see that, you'll see build.xml (and hopefully not promptly forget about it like I did). Another thing I'm not happy with is that we aren't able to generate code coverage from the 'iOS Tests (Cocoapods)' target. We only get coverage from the new 'iOS Tests (Static Library)' target. I may be overlooking something simple, like if both the gcda and gcno generating compiler flags are set in the Pods project. But, not a huge deal as coverage will be identical and we really should be checking both as long as both are supported.

The build.xml is a bit of a mess now, particularly the new 'should be private' targets. What's the motivation as to not including other targets as dependencies on private targets? This is my first time using ant; any and all tips are welcome.

[rhgills]

Thanks for the push access, by the way. Let me know if I get too cavalier with it.

[jasperblues]

The idea between the 'public' targets and 'private' targets is that:

Private targets define/modularize the actual tasks.
Public targets orchestrate the flow

This way we can easily see the sequence of events that happens in a build. . . but if we let private targets depend on each other, it can easily become hard to follow, and difficult to maintain.

Do you have a) LinkedIn b) An email address - so I can give you access to the Build Server, including failure reports.

On Jul 27, 2013, at 6:36 AM, Robert Gilliam notifications@github.com wrote:

Apologies, I completely overlooked the entire ant build system when performing my own tests. I realized that last night and spent a while looking into it. Thanks for fixing the rest of the automated build! Coverage should also be fixed now.

I added a build.sh script (which just calls ant) to hopefully make it more obvious that, hey, there's a build system here. Not sure if that's at all helpful though - if you're going to see that, you'll see build.xml (and hopefully not promptly forget about it like I did). Another thing I'm not happy with is that we aren't able to generate code coverage from the 'iOS Tests (Cocoapods)' target. We only get coverage from the new 'iOS Tests (Static Library)' target. I may be overlooking something simple, like if both the gcda and gcno generating compiler flags are set in the Pods project. But, not a huge deal as coverage will be identical and we really should be checking both as long as both are supported.

The build.xml is a bit of a mess now, particularly the new 'should be private' targets. What's the motivation as to not including other targets as dependencies on private targets? This is my first time using ant; any and all tips are welcome.

—
Reply to this email directly or view it on GitHub.

[jasperblues]

Re push access: You're very welcome. . . excellent contributions.

If you'd like to be featured on the Typhoon website, please send me a picture and short (2-3 sentences) bio.

Please keep me posted about what you're doing and discuss big changes. . Experimental changes should of course be done on a branch.

Jasper Blues
Landline: +63.2.826.2489
Skype: jasperblues
LinkedIn Twitter

On Jul 27, 2013, at 6:37 AM, Robert Gilliam notifications@github.com wrote:

Thanks for the push access, by the way. Let me know if I get too cavalier with it.

—
Reply to this email directly or view it on GitHub.

[rhgills]

Regarding the private and public targets:

That makes sense. I'll take a look at the build.xml again when I have a chance and see how I can improve it while keeping this structure.

I just added my email to my profile - robert (at) robertgilliam.org. And I'd be honored to be mentioned on the site! I'll send those to you when I have a chance.

Will of course make sure to get input on any big changes and keep things off the main branch when appropriate.

[jasperblues]

Its great that we now have iOS and OSX tests. however the way they're set up now means:

• You have to manually run clean before testing.
• Debugging won't work

[rhgills]

I haven't had to run clean before testing, is this in xcode/appcode or from the command line? Do you have to clean before running just the cocoapods test targets, or also with the iOS static library test target?

Debugging also seems to work normally for me here, when running tests within Xcode (with both the Cocoapods and Static Library targets); I just quickly doublechecked by setting a breakpoint on [TyphoonComponentFactory register:].

One thing I did notice that is a pain and might have mentioned before, I can't recall: you have to run pod install after adding a new file to the project, otherwise cocoapods doesn't include the new file in the static libraries it constructs.

[jasperblues]

Hmmm. It might be an AppCode issue then. . . It definitely doesn't quite work properly in AppCode - requires clean to be run each time. . . I'll raise an issue with AppCode.

Re CocoaPods - ah right. That sounds good - if it pulls in from the local CocoaPods spec, we can just run 'pod update' and test the Spec out each time. Nice.

(ps: I recommend running 'pod update' after the initial install, instead of 'pod install' again)

On Aug 22, 2013, at 8:38 AM, Robert Gilliam notifications@github.com wrote:

I haven't had to run clean before testing, is this in xcode/appcode or from the command line? Do you have to clean before running just the cocoapods test targets, or also with the iOS static library test target?

Debugging also seems to work normally for me here, when running tests within Xcode (with both the Cocoapods and Static Library targets); I just quickly doublechecked by setting a breakpoint on [TyphoonComponentFactory register:].

One thing I did notice that is a pain and might have mentioned before, I can't recall: you have to run pod install after adding a new file to the project, otherwise cocoapods doesn't include the new file in the static libraries it constructs.

—
Reply to this email directly or view it on GitHub.

[jasperblues]

pps: We could add a script execution to the Test Target's build phase, that does the 'pod update' as part of the command. . . Then it would be basically transparent.

Jasper Blues
Landline: +63.2.826.2489
Skype: jasperblues
LinkedIn Twitter

On Aug 22, 2013, at 1:29 PM, Jasper Blues jasper.reloaded@gmail.com wrote:

Hmmm. It might be an AppCode issue then. . . It definitely doesn't quite work properly in AppCode - requires clean to be run each time. . . I'll raise an issue with AppCode.

Re CocoaPods - ah right. That sounds good - if it pulls in from the local CocoaPods spec, we can just run 'pod update' and test the Spec out each time. Nice.

(ps: I recommend running 'pod update' after the initial install, instead of 'pod install' again)

On Aug 22, 2013, at 8:38 AM, Robert Gilliam notifications@github.com wrote:

I haven't had to run clean before testing, is this in xcode/appcode or from the command line? Do you have to clean before running just the cocoapods test targets, or also with the iOS static library test target?

Debugging also seems to work normally for me here, when running tests within Xcode (with both the Cocoapods and Static Library targets); I just quickly doublechecked by setting a breakpoint on [TyphoonComponentFactory register:].

One thing I did notice that is a pain and might have mentioned before, I can't recall: you have to run pod install after adding a new file to the project, otherwise cocoapods doesn't include the new file in the static libraries it constructs.

—
Reply to this email directly or view it on GitHub.

[rhgills]

Right, pod update makes much more sense. Don't ask me how I got into the bad pod install habit, but I'll try and clean up my act. :)

I've started using AppCode recently, so I quickly hopped in there to check. Debugging all the test targets works OK for me. I'm sure this isn't the problem you're having, but I still have the hardest time remembering that AppCode won't attach the debugger when just 'running', only when 'debugging'. Just tripped me up again for a few seconds.

re: pps: Great idea! 👍

[jasperblues]

I did exactly the same thing at first - pod install. . .. I think everyone does - the docs are missing something . . .

hhmmm. . don't know what's happening with me and AppCode then. . .

Just about to fix the Bamboo build. . .

On Aug 23, 2013, at 10:57 AM, Robert Gilliam notifications@github.com wrote:

Right, pod update makes much more sense. Don't ask me how I got into the bad pod install habit, but I'll try and clean up my act. :)

I've started using AppCode recently, so I quickly hopped in there to check. Debugging all the test targets works OK for me. I'm sure this isn't the problem you're having, but I still have the hardest time remembering that AppCode won't attach the debugger when just 'running', only when 'debugging'. Just tripped me up again for a few seconds.

re: pps: Great idea!

—
Reply to this email directly or view it on GitHub.

[rhgills]

I've been having some strange issues with unit tests that link to and test static libraries with AppCode recently. There have definitely been a few times where I have had to clean the test target before running the unit tests would exercise, say, a piece of logging code that I had added to the static library target.

I'll keep you updated once I've had a chance to look into this more.

[jasperblues]

Ah, i thought so! . . . I will log a bug with Jetbrains today, if you can confirm that it doesn't do this in XCode.

[rhgills]

I can confirm this issue is not present in XCode.

steps to verify in Xcode:

• run iOS Unit Tests (Static Library)
• Added an NSLog to -[TyphoonComponentFactory load]
• run iOS Unit Tests (Static Library)
• verify that newly added NSLog outputs to console

And in AppCode:

• run iOS Unit Tests (Static Library)
• Added an NSLog to -[TyphoonComponentFactory load]
• run iOS Unit Tests (Static Library)
• The newly added NSLog does NOT output.
• clean
• run tests again
• the newly added NSLog outputs as expected