@testable is a very useful feature, however I've recently had several bugs caused by accidentally accessing
internal symbols, or rather, by forgetting to declare symbols in a framework
So I'm wondering if it was a mistake to make
@testable allow access to all symbols with
internal visibility, and whether it should be changed to just provide access to symbols that are explicitly marked with a special
For all other intents and purposes,
testable would be identical to
internal. The only difference would be that
@testable import only makes
testable symbols accessible, all symbols marked as
internal stay in-accessible.
This would have several benefits:
- It means unit tests can not accidentally access
internalsymbols that should have been made
public. Unit tests can verify correct visibility of symbols too.
- The few spots where internals are exposed to tests are explicit in the code, not just in the tests.
The downsides would be:
- This would be a source-breaking change. All tested code would need to be updated to mark internal symbols used in tests with the new
testablevisibility. (Since accesses to internal symbols are a hard error though, I think it'd be possible to add a Fix-it for that)
- If you are writing additional tests for someone else's library, you would be unable to write tests that use internal symbols without submitting an upstream patch to make their visibility
What do you people think? Strong reasons against this? Would you want this too?