Reputation: 4850
When writing unit test with OCUnit it's possible to omit the test method definition in the public interface (.h). But what is the best practice for OCUnit regarding test methods definitions in public interface?
ModelTest.h (no test methods defined)
@interface ModelTest : SenTestCase
@end
ModelTest.m
@implementation ModelTest : SenTestCase
- (void) testCreation {
...
}
@end
ModelTest.h (with test method definitions)
@interface ModelTest : SenTestCase
- (void) testCreation;
@end
Personally I think it's better to have a public test method definition reflected in the public interface. But what is the best practice? Is there a case when we can't avoid declaring these methods in public interface?
Upvotes: 0
Views: 178
Reputation: 20980
I don't use a separate .h and .m for OCUnit tests; everything goes into .m
The only reason to put something in the interface is so that another class can discover it. But tests are found by reflection, not by code referencing specific names of test cases.
See https://qualitycoding.org/unit-test-template/ for the template I use, and why.
Upvotes: 1
Reputation: 2080
It's rare for a non-test class to depend on a test class; no one is going to #include your ModelTest declarations. So there's not a lot to be gained from encapsulation or from exposing the test methods. The test runner will see them in any case.
It may be useful to declare them in the .h file if you are generating documentation from your headers.
Occasionally, you might define a subclass of SenTestCase that adds special auxiliary methods for your tests. If you do that, you might not want to make test methods public on the superclass. But then, it might be better to remove the test cases from the superclass entirely, treating the superclass as an abstract interface that just holds the auxiliary methods.
Upvotes: 2