Xcode: TEST vs DEBUG preprocessor macros
Solution 1
Instead of creating a Test build configuration, I:
created a
Tests-Prefix.pch
file:#define TEST 1 #import <SenTestingKit/SenTestingKit.h> #import "CocoaPlant-Prefix.pch"
entered its path in the Prefix Header field of the Tests target's build settings.
added the following code to the top of a file I created called
MyAppDefines.h
, imported inMyApp-Prefix.pch
:#ifdef TEST #define TEST_CLASS NSClassFromString(@"AppDelegateTests") // any test class #define BUNDLE [NSBundle bundleForClass:TEST_CLASS] #define APP_NAME @"Tests" #else #define BUNDLE [NSBundle mainBundle] #define APP_NAME [[BUNDLE infoDictionary] objectForKey:(NSString *)kCFBundleNameKey] #endif
This allows me to use BUNDLE
where ever I mean [NSBundle mainBundle]
and also have it work when I run Tests.
Importing SenTestingKit in Tests-Prefix.pch
also speeds up the compiling of the SenTestingKit Framework and allows me to leave out #import <SenTestingKit/SenTestingKit.h>
from the top of all the tests files.
Solution 2
Preprocessor macros will not work, you need to check the environment at runtime.
Objective-c
static BOOL isRunningTests(void)
{
NSDictionary* environment = [[NSProcessInfo processInfo] environment];
return (environment[@"XCTestConfigurationFilePath"] != nil);
}
Swift
var unitTesting : Bool
{
return ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil
}
(Updated for Xcode 11)
Solution 3
You might consider adding a new build configuration.
In xcode 4, click on your project on the left hand navigator.
In the main window, click on your project, and then select the "info" tab.
Click the "+" button to add a new configuration (you can call yours "test" if you like").
Now, click on your target, and go to the build settings tab.
Search for "preprocessor macros"
Here, you can add preprocessor macros for your new build configuration.
Just double click on your new "test" configuration, and add TESTING=1.
Finally, edit your build scheme. Select the test options for your scheme. There should be a "Build Configuration" drop down menu. Select your "test" configuration.
Solution 4
I decided to add a check for an environment variable in the code itself, instead of using the isRunningTests() suggestion Robert made.
- Edit the current Scheme (Product/Scheme/Edit Scheme) or Command+<
- Click on the Test configuration
- Click on Arguments Uncheck "Use the Run action's arguments and environment variables
- Expand Environment Variable section and add the variable TESTING with value YES
- Add this to your code somewhere and call is whenever you need to:
+ (BOOL) isTesting { NSDictionary* environment = [[NSProcessInfo processInfo] environment]; return [environment objectForKey:@"TESTING"] != nil; }
The screen should look like this when you are done.
The code above will find the TESTING environment variable when running in test mode or application mode. This code goes in your application, not the unit test files. You can use
#ifdef DEBUG
...
#endif
To prevent the code from being executed in production.
Solution 5
If you create a Test build configuration and then set the "Other Swift Flags" property of your Target to "-DTEST" it will define a TEST macro that will work in your swift code. Make sure you set it in the build settings of your App target so that you can use it in your App's Swift code.
Then with this set, you can test your code like so:
func testMacro() {
#if !TEST
// skipping over this block of code for unit tests
#endif
}
ma11hew28
Updated on September 25, 2020Comments
-
ma11hew28 almost 4 years
When creating a new project with unit tests, Xcode sets the build configuration to Debug for the Test scheme (same for the Run scheme).
Should I differentiate between Run (Command-R) & Test (Command-U) schemes?
I.e., should I create a new Build Configuration called Test, add a preprocessor macro TEST=1 to it, and use it as the build configuration for the Test scheme instead? Or, should I just keep Run & Test both as Debug?
I come from a Ruby/Rails background, where you usually have test, development, and production environments. It seems to me that Debug is like development and Release is like production, but we're missing a test, which is why I'm thinking it might make sense to add Test.
Comments? Opinions? Suggestions?
I'm specifically asking this because I want to compile something for Test with:
#ifdef TEST // Do something when I test. #endif
I don't think it matters if I also compile this for Debug. So, I really could just do:
#ifdef DEBUG // Do something when I run or test. #endif
But, I'm really only intending to do it for tests for now. So, that's why I'm thinking I should differentiate between debug & test but am wondering why Xcode doesn't do that for you by default? Does Apple think you shouldn't differentiate between them?
-
shawnwall about 12 yearsAdding a #define TEST 1 to my unit test target preprocessor macro sets the macro within the executing unit test code, but not in the code in the app that is being unit tested. Any idea how I can accomplish this?
-
yonel about 12 yearsFacing the same issue as @shawnwall : the TEST variable isn't in the context of the compiler when compiling the app. It's there just when compiling the test case itself.
-
marklar almost 11 yearsDid you guys ever figure this out? Having the same problem.
-
jab over 10 yearsFound an answer below to these comment-questions: stackoverflow.com/a/13928458/623999 .
-
jab over 10 yearsSo in other words, for any file in the main target where you want the
TEST
preprocessor macro to be defined during testing, add that file to the "Compile Sources" list under "Build Phases" in your test target. -
jab over 10 yearsAnother thing that works in XCTest is that
[UIApplication sharedApplication]
returns nil during testing. I can't imagine another scenario where that would be nil, so I've used it as a testing flag before (please comment if I'm wrong!). -
Chris Gillum about 10 yearsI found David's answer to be far simpler: stackoverflow.com/a/14718914/2069
-
Lukas Gross over 9 yearsThis is by far the best way to do this if you want to have preprocessor macros not only available in your test code but also in the regular app. Much cleaner than the other solutions using helper methods. Still works perfectly in Xcode6
-
Snowman over 8 yearsIf you're using Cocoapods, make sure you run
pod install
after creating the new build configuration. -
Andrea Zonca about 8 yearsblog post link is broken
-
Ayush Goel about 8 yearsThis environment variable is not being set in Xcode 7.3.1
-
Robert about 8 years@AyushGoel - Thanks for the heads up. Best thing to do is to check the the contents of the environment dictionary. Seems like you can look for the
XCInjectBundleInto
key. Ill update this shortly. -
Milan Cermak almost 8 yearsSwift version for fast copy-paste:
func isRunningTests() -> Bool { let env: [String: String] = NSProcessInfo.processInfo().environment return env["XCInjectBundleInto"] != nil }