Objective-c – Best way to capture key events in NSTextView

Xcode includes XCTest, which is similar to OCUnit, an Objective-C unit testing framework, and has full support for running XCTest-based unit tests as part of your project's build process. Xcode's unit testing support is described in the Xcode Overview: Using Unit Tests.

Back in the Xcode 2 days, I wrote a series of weblog posts about how to perform some common tasks with Xcode unit testing:

• Unit testing Cocoa frameworks
• Debugging Cocoa framework unit tests
• Unit testing Cocoa applications
• Debugging Cocoa application unit tests

Despite using OCUnit rather than XCTest, the concepts are largely the same.

Finally, I also wrote a few posts on how to write tests for Cocoa user interfaces; the way Cocoa is structured makes it relatively straightforward, because you don't have to spin an event loop or anything like that in most cases.

• Trust, but verify.
• Unit testing Cocoa user interfaces: Target-Action
• Unit testing Cocoa user interfaces: Cocoa Bindings

This makes it possible to do test-driven development for not just your model-level code but also your controller-level and even view-level code.

There isn't, as others have already said, such a thing as a private method in Objective-C. However, starting in Objective-C 2.0 (meaning Mac OS X Leopard, iPhone OS 2.0, and later) you can create a category with an empty name (i.e. @interface MyClass ()) called Class Extension. What's unique about a class extension is that the method implementations must go in the same @implementation MyClass as the public methods. So I structure my classes like this:

In the .h file:

@interface MyClass {
    // My Instance Variables
}

- (void)myPublicMethod;

@end

And in the .m file:

@interface MyClass()

- (void)myPrivateMethod;

@end

@implementation MyClass

- (void)myPublicMethod {
    // Implementation goes here
}

- (void)myPrivateMethod {
    // Implementation goes here
}

@end

I think the greatest advantage of this approach is that it allows you to group your method implementations by functionality, not by the (sometimes arbitrary) public/private distinction.