iPhone Xcode是否可以在不加载模拟器的情况下测试方法？

Question

I'm trying to test some simple string manipulation methods I need for my iPhone project. I was wondering if there was anyway of testing the results of methods without loading the simulator each time..

for instance in my main.m method:

#import <UIKit/UIKit.h>

int main(int argc, char *argv[]) {
        testMethod();
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}


void testMethod() {
    NSString *body = @"{\"username\":\"name\",\"password\":\"123\"}";
    NSLog(@"body=%@",body);
}

All I want to do is run this code and see what the console outputs (no simulator needed). Is this possible in xCode?

Answer 1

Not really, no. If you really want to, you could create a new Xcode project as just a "command line utility" (under the Mac OS X templates) that'd run faster because it doesn't have to load the simulator. If you're just doing NSString manipulation, the same code will work on Mac OS X.

Answer 2

This is a perfect situation for Unit Testing . For iPhone development, I've been using GH-Unit .

There's going to be some overhead setting up GH-Unit and learning how to write proper unit tests, but the payoff will be that:

1. You'll be able to quickly write and test your method and be confident that it's working correctly.
2. The tests will exist in perpetuity, so you can refactor your test method and be sure that you aren't breaking anything.

The biggest benefit of unit testing that I never hear anyone talk about is how quickly it allows you to fix bugs. When you or a tester finds bug in your app, you can quickly write a unit test to recreate the situation that causes the bug, re-write the code to handle the bug, then run the tests, all without ever compiling and running your app. For bugs buried deep in a navigation hierarchy, this is a huge win.

One other benefit I just remembered, good unit tests let you walk through using your classes/methods in practice mode, before you write a whole bunch of code that depends on a specific interface. This is a great way to ferret out those awkward little workflows that seemed like a great idea until you had to actually start using them.

Yet another benefit: self documentation. If you ever need to give someone sample code on how to use your classes, just copy and paste code out of a unit test.

I don't do test-driven-development and I'm not anal about 100% coverage, but as you can probably tell from this post, I love me some unit tests. I used to jump through all kinds of awkward hoops, setting up little terminal-based projects to let me test my classes without the overhead of running the entire app. After a while I realized how stupid it all was and put my mind to learning how to test my classes. It's made a huge difference in my productivity.

---

@jlehr suggested OCUnit, which does have better integration with Xcode and is a lot easier to set up. I would stay away from OCUnit on the iPhone, though. I had a lot of issues running my unit tests in the debugger while in the simulator with OCUnit. If you can write perfect unit tests first try, maybe this isn't a problem :-D GHUnit lets you debug your unit tests right out of the box.

This is just for iPhone dev, though. If you're on OS X, than OCUnit is a great choice for your unit tests. There's a lot of other test frameworks out there, but GHUnit is the only one I've tried to use that works very well with iPhone development.