Remember that there’s actually no such thing as “private methods” in Objective-C, and it’s not just because it’s a dynamic language. By design, Objective-C has visibility modifiers for ivars, but not for methods — it’s not by accident that you can call any method you like.
@Peter‘s suggestion is a great one. To complement his answer, an alternative I’ve used (when I don’t want/need a header just for private methods) is to declare a category in the unit test file itself. (I use @interface MyClass (Test) as the name.) This is a great way to add methods that would be unnecessary bloat in the release code, such as for accessing ivars that the class under test has access to. (This is obviously less of an issue when properties are used.)
I’ve found this approach makes it easy to expose and verify internal state, as well as adding test-only methods. For example, in this unit test file, I wrote an -isValid method for verifying correctness of a binary heap. In production, this method would be a waste of space, since I assume a heap is valid — I only care about it when testing for unit test regressions if I modify the code.