Unit Testing Preprocessor Macros in Swift

Preprocessor macros are used to bring context to a build, allowing you to transform how your app is compiled depending on why it's being built.

In iOS, preprocessors are popularly used to determine which scheme was used to build an app. This allows you to build things such as debug views which are only visible in debug builds, additional logging for non-AppStore builds, and more. My favorite use of macros is using the Factory pattern to return mocked components for XCUITests:

enum HTTPClientFactory {
    static func createClient() -> HTTPClient {
        #if TESTING
            return MockHTTPClient()
        #else
            return URLSessionHTTPClient()
        #end
    }
}

Additionally, preprocessor macros have the incredible ability to change how your code is compiled. As the prefix "pre" implies, the value of a macro is tested before your code is compiled, meaning that everything in the "else" block of a preprocessor macros will not be present in the final binary. For things like debug views and mocked components, this is an amazing feature. As the code in the else block is ignored, a hacker that decompiles your app would not find a single trace that such features even existed.

Preprocessor Macros Unit Testing Issues

However, this same amazing feature also brings amazing problems. Since the code is ignored, you might have witnessed the fact that testing them can be very difficult. Unless you create multiple testing schemes with multiple macro settings (please don't do this), you are not easily able to test how your app behaves depending on the value of the macro -- only the value that your testing scheme is currently using. For example, in the createClient() snippet above, I would able to test that createClient() returns a MockHTTPClient as my testing scheme defines the TESTING macro, but I wouldn't be able to confirm that it returns a URLSessionHTTPClient in other situations.

This might lead you to other alternatives, like using compiler arguments or a global property instead of the macro directly:

var isDebugging = false

func userDidShakeDevice() {
    if isDebugging {
        pushDebugMenu()
    }
}

func startApp() {
	#if DEBUG_SCHEME
	isDebugging = true
	#endif
	...
}

In this case, it's a lot easier for a unit test to override the value of the macro, as all we have to do is toggle the global isDebugging property. Unfortunately, while this works, you're giving up the macro's ability to erase your code. The usage of if isDebugging in this case tells the compiler that the execution of userDidShakeDevice() is unknown in compile time due to the fact that the value of that boolean can change any time. This would compile the if block even if you're running a non-debug build, allowing hackers to find the pushDebugMenu() method and use it for evil.

Leveraging Optimization Settings to Unit Test Preprocessor Macros

Fortunately, by leveraging the Swift Compiler's ability to ignore unused code, we can mix the best of both worlds and achieve macros that properly erase code and are easily testable at the same time.

To explain how to achieve this, let's use a real example. In one of the companies I worked for, for bug-finding reasons, employees couldn't install AppStore builds -- only beta ones. This was done by detecting which build you had installed and checking your user's permissions to see if you were allowed to use it. Otherwise, you would get an alert showing you where to download the correct version. The detection part was done like this:

enum BuildType {
    case appStore
    case employeeBuild
    case xcodeBuild
}

var currentBuildType: BuildType {
    #if ENTERPRISE
    return .employeeBuild
    #elseif XCODE
    return .xcodeBuild
    #else
    return .appStore
    #endif
}

As we can see, this is exactly like our previous examples, with the exact same issues as we had no way to test that currentBuildType returned the correct build type for each build.

Before learning how we can test this, let's clean this up by abstracting the macro checks into separate types:

enum EnterpriseMacro {
    static var active: Bool {
        #if ENTERPRISE
        return true
        #else
        return false
        #endif
    }
}

enum XcodeMacro {
    static var active: Bool {
        #if XCODE
        return true
        #else
        return false
        #endif
    }
}

var currentBuildType: BuildType {
    if EnterpriseMacro.active {
        return .employeeBuild
    } else if XcodeMacro.active {
        return .xcodeBuild
    } else {
        return .appStore
    }
}

Wait! Doesn't this have the same problem as the global property example?

If this is what you thought, congratulations! The answer is it depends, and this is exactly what we're going to leverage to unit test this class. The global property is problematic because its value can change in runtime, but our macro type's active properties are immutable. If you compile your app without optimization (true for debug and testing builds), the compiler will behave exactly like in the global property example, but if you compile with optimization (true for release builds), since our active values are immutable, the compiler will erase the unreachable parts of the code.

We can confirm this by dumping Swift's SIL, which can be thought of as the final version of your code:

swiftc -emit-sil ./bla.swift -O -DXCODE

// currentBuildType.getter
sil hidden @$s3bla16currentBuildTypeAA0cD0Ovg : $@convention(thin) () -> BuildType {
bb0:
  %0 = enum $BuildType, #BuildType.xcodeBuild!enumelt // user: %1
  return %0 : $BuildType                          // id: %1
} // end sil function '$s3bla16currentBuildTypeAA0cD0Ovg'

The SIL indicates that when that file is compiled with optimization and the XCODE macro, currentBuildType instantly returns .xcodeBuild. Traces of the other build types in this method have been completely eliminated!

(Note: This method still isn't hacker-proof because the other build types are still defined in the enum. Use this as an example of how to unit test macros, but consider the security necessities when implementing the trick shown in this article.)

Unit Testing the Macros

Finally, to test these macros, we can simply add a property to override its value when the macro isn't present:

protocol Macro {
    static var isOverridden: Bool { get set }
}

enum EnterpriseMacro: Macro {
    static var isOverridden = false

    static var active: Bool {
        #if ENTERPRISE
        return true
        #else
        return isOverridden
        #endif
    }
}

Even though a hacker is able to force isOverridden to be true, nothing would be achieved as the code that ran as the result of the presence of this macro was never compiled.

Changing isOverridden would only have an effect if we compiled our code without optimizations, which is exactly the case of unit testing targets. We can then use it to safely unit test currentBuildType.

func with<T: Macro>(macro: T.Type, block: () -> Void) {
    macro.isOverridden = true
    block()
    macro.isOverridden = false
}

final class BuildTests: XCTestCase {
    func testEnterpriseBuild() {
        with(macro: EnterpriseMacro.self) {
            XCTAssertEqual(currentBuildType, .employeeBuild)
        }
    }

    func testDebugBuild() {
        with(macro: XcodeMacro.self) {
            XCTAssertEqual(currentBuildType, .xcodeBuild)
        }
    }

    func testProductionBuild() {
        // How it behaves when no macros are present
        XCTAssertEqual(currentBuildType, .appStore)
    }
}

(Note that because isOverridden only works when a macro isn't present in the build, your testing target should not contain macros whose's presence/absence needs to be tested.)

With this setup, we're able to test preprocessor macros while being sure that our final release builds will not contain code that's not meant to be executed. This same trick can be used to test macros in XCUITests.

As a final note in the topic of security, note that if your intention is to completely get rid of something in runtime, everything needs to be wrapped by macro checks. In this case, if hiding the build types themselves was critical (and not just the logic of what's my current one), we would have to wrap the enum itself in macros, which would make unit testing it like this considerably harder, although still possible.