I have 2 test classes in a XCode 5 project:
ABCDataModelTests.{h,m}
- (void)testAlwaysPassing { ... }
ABCDataModelListColorsTests.m which inherits from ABCDataModelTests.
- (void)testNumberOfListColorsGreaterThan7 { ... }
When I ran the test, I noticed that there is a symbol "rT" underneath the subclass's tests as shown in the picture.
What does "rT" stand for? Note that the subclass inherits the test method "testAlwaysPassing."
I can't find anything in the Apple documentation for "New Features in XCode 5/5.0.1" Is there any documentation for what all the symbols stand for?
XCTest is the automation testing framework provided in Xcode with built-in support to help you set up and execute your tests. Testing is an important step of developing any project which can help you find bugs in your source code.
You do not need to include unit tests. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application.
I found this information on some forums:
The standard way to do things in SenTestingKit/OCUnit/XCTest is to declare your tests in code. If you do, Xcode will discover them statically (ie. not at runtime) using the index. Once Xcode these tests are discovered, they show up in the test navigator with a "t" icon. So far so good.
Now, the SenTestingKit/OCUnit/XCTest frameworks also allow you to create tests on the fly at runtime. Some of our users make creative user of this capability, perhaps to wrap an external testing system or to create tests to represent a dynamic set of data. Xcode cannot discover these tests statically, and only find out about their existence when they are returning resutls during a test run. When discovered, they will show up in the test navigator with a "rT" icon. "rT" being short for "runtime discovered tests".
Finally. If there's anything wrong / unusual about your project that prevents indexing from completing or from properly parsing your test classes, then your tests wouldn't be statically discovered. You may still successfully build and run them, in which case Xcode would end up treating them as runtime discovered tests, and give them the "rT" icon.
Interesting. I have been very annoyed by the same problem with a test class I created by duplicating another file in the IDE. I have duplicated other test files before so that doesn't seem to be the problem.
The test class has only a single test inside it and another side-effect of the purple icon and classification of it as a runtime test is that you can't trigger the test with the little triangle icon offered in the test runner for the other tests or test classes.
The contextual menu in the test explorer offers Test "testBlah" which seems to exercise the test.
Quitting XCode, deleting the xcuserdata folder and rebuilding made the test recognised again as a normal test.
I am getting reminders of older Visual Studio versions which used to have caching problems and needed regular deletion of their local context data!
I agree with what @everyday_productive said
"rT" usually means something wrong with indexing, to fix this go to terminal and type the following:
$ cd ~/Library/Developer/Xcode/
Make sure your Xcode is terminated then delete "Derived Data" folder.
Deleting derived data didn't help me to get rid of running these tests. So I've created a small category on XCTestCase
and it worked:
#import "XCTestCase+TestCaseSwizzling.h"
@import ObjectiveC.runtime;
static NSMutableSet* alreadyRunTests = nil;
@implementation XCTestCase (TestCaseSwizzling)
+ (void)load
{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
alreadyRunTests = [NSMutableSet set];
Class class = [self class];
SEL originalSelector = @selector(invokeTest);
SEL swizzledSelector = @selector(swizzledInvokeTest);
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
method_exchangeImplementations(originalMethod, swizzledMethod);
});
}
- (void)swizzledInvokeTest
{
NSString* selectorString = NSStringFromSelector(self.invocation.selector);
if (![alreadyRunTests containsObject:selectorString])
{
[alreadyRunTests addObject:selectorString];
[self swizzledInvokeTest];
}
}
@end
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With