Why would I ever NOT want to Enable Testability

Question

In ios apps the default behaviour appears to be to fail for Test Compilation.

Why would I want that to be default? Surely, at worst, I would want Debug to have it enabled? What changes does Enabling Testability actually make?

Answer 1

I happened upon this while tracking down another issue. But perhaps I can give provide a scenario. Why would you ever not want to enable testability?

-fvisibility=hidden.

If you want to use the GCC_SYMBOLS_PRIVATE_EXTERN (aka Symbols Hidden By Default), enable testability has higher precedence and will override this.

In my case, I have a configuration which is copied from Debug and hence has Enable Testability == YES. I have an external static library which was built with -fvisibility=hidden which is used to build one of my own static libs (built with Xcode). However when building my debug builds, I get errors such as (I redacted the function names and paths)

Showing All Messages : Direct access in function ... means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

From the Apple doc here:

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/04-writing_tests.html

When you set the Enable Testability build setting to Yes, which is true by default for test builds in new projects, Xcode includes the -enable-testing flag during compilation. This makes the Swift entities declared in the compiled module eligible for a higher level of access.

It would seem that it is also there for Swift accessibility. So if you are not using Xcode's testing and Swift, it would also seem like you could do without this.