Swift: Testing Privates
There's an awful joke in here somewhere
David Owens II writes about Swift access control and unit tests. He's currently adding his source files directly to the unit test target so the internal members are visible to the tests.
That's probably the best solution possible currently, but I'm filing a radar to add the equivalent of InternalsVisibleTo
. In C#, that attribute is set at the assembly (think module) level and specifies what other assemblies (modules) have access to the internal
members. It allows you to do unit testing without compromising your public interfaces and allows two modules you create to work together if needed. Naturally that can be a double-edged sword.
I think we need an equivalent Swift compiler setting that allows us to specify that a given target should make its internal members visible to certain other modules. Purists may decry that as a hole in the access protection, but in reality I can always hook up a debugger and jump directly to whatever functions I like so access protection is really just a way for us to enforce the rules we want to enforce, not an actual security access protection mechanism like sandboxing or file permissions.
This blog represents my own personal opinion and is not endorsed by my employer.