Unit testing private method - objective C

Question

I use GHUnit. I want to unit test private methods and don't know how to test them. I found a lot of answers on why to or why not to test private methods. But did not find on how to test them.

I would not like to discuss whether I should test privates or not but will focus on how to test it.

Can anybody give me an example of how to test private method?

Answer 1

Methods in Objective-C are not really private. The error message you are getting is that the compiler can't verify that the method you are calling exists as it is not declared in the public interface.

The way to get around this is to expose the private methods in a class category, which tells the compiler that the methods exist.

So add something like this to the top of your test case file:

@interface SUTClass (Testing)

- (void)somePrivateMethodInYourClass;

@end

SUTClass is the actual name of the class you are writing tests for.

This will make your private method visible, and you can test it without the compiler warnings.

Answer 2

A little late, but I just got onto the TDD train.

Private methods shouldn't be tested. Because you write private methods to support your public methods, thus testing your public methods indirectly tests the private methods which support them.

The principle "private methods shouldn't be tested" is supported by the principle "when you need to test private methods, it probably means that you should move those methods to the separate class", thus making them public.

Answer 3

If a method is private, you never should test it.

Think about this. You should test behaviour and contract of your methods instead internal implementation

Answer 4

Agreed with @Lord Zsolt

Also please note next (from Test-Driven iOS Development ISBN-10: 0-321-77418-3, ISBN-13: 978-0-321-77418-7 )

Testing Private Methods

I have often been asked, “Should I test my private methods?” or the related question “How should I test my private methods?” People asking the second question have assumed that the answer to the first is “Yes” and are now looking for a way to expose their classes’ pri- vate interfaces in their test suites.

My answer relies on observation of a subtle fact: You already have tested your private meth- ods. By following the red–green–refactor approach common in test-driven development, you designed your objects’ public APIs to do the work those objects need to do. With that work specified by the tests—and the continued execution of the tests assuring you that you haven’t broken anything—you are free to organize the internal plumbing of your classes as you see fit. Your private methods are already tested because all you’re doing is refactoring behavior that you already have tests for.

You should never end up in a situation where a private method is untested or incompletely tested, because you create them only when you see an opportunity to clean up the implementation of public methods. This ensures that the pri- vate methods exist only to support the class’s public behavior, and that they must be invoked during testing because they are definitely being called from public methods.