-
Notifications
You must be signed in to change notification settings - Fork 269
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
Add iOS unit tests, replace unit test dependencies with cocoapods, fix iOS build errors #32
Conversation
Add iOS unit tests, replace unit test dependencies with cocoapods, fix iOS build errors
Thanks Robert! |
My pleasure! |
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. . . |
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. |
Thanks for the push access, by the way. Let me know if I get too cavalier with it. |
The idea between the 'public' targets and 'private' targets is that: Private targets define/modularize the actual tasks. 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:
|
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 On Jul 27, 2013, at 6:37 AM, Robert Gilliam notifications@github.com wrote:
|
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. |
Its great that we now have iOS and OSX tests. however the way they're set up now means:
|
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 One thing I did notice that is a pain and might have mentioned before, I can't recall: you have to run |
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:
|
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 On Aug 22, 2013, at 1:29 PM, Jasper Blues jasper.reloaded@gmail.com wrote:
|
Right, 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! 👍 |
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:
|
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. |
Ah, i thought so! . . . I will log a bug with Jetbrains today, if you can confirm that it doesn't do this in XCode. |
I can confirm this issue is not present in XCode. steps to verify in Xcode:
And in AppCode:
|
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 changingisEqualTo:
toisEqual:
, 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!