Open Radar

 
Currently, all -(void)test... methods in any subclass of SenTestCase are automatically detected and executed. However, sometimes test methods need only be run in subclasses of the test class in which they are defined. For example, if a hierarchy of test classes might be created to mimic the hierarchy of classes under test, which has a parent class that should be treated as abstract (non-instantiable), and multiple subclasses that have additional (and possibly disparate) behaviors to test. A good example of this might be class clusters, where the parent class does not implement the primitive methods, but only those that use primitive methods.

To work around this, I currently begin each such test method by checking the class of the current test case and bailing out if it is the parent class. For example:

	if ([self isMemberOfClass:[MyParentTest class]]) return;

Among other downsides, this becomes repetitive, particularly if one's unit tests are highly granular and includes lots of test methods. (Macros mask the problem of repeated code, but don't actually solve it or other issues.) In addition, the tests are still executed and reported as successes, inflating the number of meaningful tests that were actually run. Unnecessary work is also performed, prolonging the execution time. (There is some overhead of invoking the methods, sending notifications, and logging the results of tests; the potential savings depends on the number and complexity of all the existing test methods.)

One solution would be to have a way for a class to signal to OCUnit that it exists only to provide methods to its subclasses, and should not actually be instantiated or executed. For example, OCUnit could call a method like +(BOOL)isAbstractTest and only run tests for a class if it returns NO. (Conversely, something like +(BOOL)shouldRunTests and YES could be used instead.) This could be made backwards-compatible by defining a default method implementation in SenTestCase that signals that all tests should be run; classes that don't override the method would be unaffected. A -respondsToSelector: call could be made first to handle running tests built against an earlier version of SenTestingKit.framework.

Also related: http://stackoverflow.com/questions/2385670/