> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Yes, it’s per file. It’s also added in the initial template that Xcode
> creates with your project. In addition, it’s recommended by many that talk
> about “how to unit test in Swift.” So, to someone that is not paying
> scrupulous attention, there is no mechanism to prevent against this today.
Perhaps we're not doing a good job of messaging this.
The Xcode template is the way it is because @testable imports are the right
default for a *program* written in Swift. A lot of the code in an application
or command-line program isn't really suitable for independent, in-process
black-box testing, because it isn't really presenting an integrated API. If
you break it down into components that can be independently tested, that's
awesome, and at that point you can switch the imports in your tests over to
non-@testable. But we don't want the test template to create any obstacles to
testing, because as you say, people already don't write enough tests.
In contrast, a library developer needs to be more conscientious about the
difference between black-box and white-box testing. In fact, they should
really be leaning towards making black-box tests whenever that's reasonably
practical. We don't currently have Xcode templates around making Swift
libraries, though; I think we all agree that there's a lot of room for tools
improvement there.
John.
> This also assumes that people write tests… which, well, we know is not the
> case at all.
>
> I guess time will tell if this should be a warning/error or not depending on
> the usage of the various Swift linters that I’m sure will start to become
> prevalent. I know it’s something I’ll be enabling in my code.
>
> It seems this design is acceptable and by-design.
>
> -David
>
>
>> On Jul 27, 2016, at 6:36 PM, Brent Royal-Gordon <br...@architechies.com>
>> wrote:
>>
>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
