> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I brought this up in review, but there seems to be a serious testability
> problem here because of how special @testable is.
>
> // This class is not subclassable outside of ModuleA.
> public class NonSubclassableParentClass {
> // This method is not overridable outside of ModuleA.
> public func foo() {}
>
> // This method is not overridable outside of ModuleA because
> // its class restricts its access level.
> // It is not invalid to declare it as `open`.
> open func bar() {}
>
> // The behavior of `final` methods remains unchanged.
> public final func baz() {}
> }
>
> In a unit test, I *can* subclass `NonSubclassableParentClass`, the access
> level of `NonSubclassableParentClass` is irrelevant. There’s now no
> programatic way to ensure that I’m actually testing the contract that I had
> intended to provide to the consumers of my framework (that my class is
> subclassable). Is this really the intention?
I could be wrong, but isn't `@testable import` applied per-file? So if you keep
code users should actually be able to write in one file with a non-`@testable`
import, and mocks and other testing hacks in a different file with an
`@testable` import, the first file should fail to compile if you use anything
that's not normally permitted.
In a future version of Swift, we might consider refining this by requiring
people to apply `@testable` directly to declarations which treat something
closed as if it's open, but it seems like even the current feature set does not
make testing impossible.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
