views:

30

answers:

2

I'm currently using OCUnit that ships with Xcode 3.2.4 for doing unit testing of my application. My workflow is often to set some break points in a failing unittestin order to quickly inspect the state. I'm using Apple's OCUnit setup:

http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/135-Unit_Testing_Applications/unit_testing_applications.html

but the setup from above gives me some headaches. Apple distinguish between Application tests and Logic tests. As I see it:

  • You cannot debug logic tests. It's as if they're invisibly run when you build your project.

  • You can debug application tests, but you have to run these on the device and not the simulator (what is the reason for this?)

This means that everything moves kind of slowly with my current workflow. Any hints on getting app tests to run on the simulator? Or any pin pointers to another test-framework? Would eg. google-toolbox-for-mac work better in general or for my specific needs?

Also, general comments on using breakpoints in the unit tests are welcome! :-)

A: 

I have used the Google Toolbox testing rig in the past and it worked fine, it ran both on the Simulator and the device and I could debug my tests if I wanted to. Recently I got fed up with bundling so much code with each of my projects and tried the Apple way.

I also find the logic/app tests split weird, especially as I can’t find any way to debug the logic tests now. (And if you’re using some parts of AVFoundation that won’t build for Simulator, you are apparently out of luck with logic tests completely, which seems strange.) One of the pros is that I can run the logic tests quickly during build.

I guess this does not help you that much – the point is that you can debug the tests under GTM. And you might also want to check out this related question.

zoul
A: 

I know this isn't really a good answer, nor is it completely helpful to your cause. But I've been using NSLog to run my unit tests (if nothing outputs to the console, then success). When I comment out my tests method then the tests wouldn't run. I found this much more predictable and reliable than OCUnit. I'd much rather use a real true unit tester, but it was too frustrating to deal with the often strange errors that could occur from OCUnit and also the other shortfalls/lack of features you describe above.

Chad