<div dir="ltr">On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 27, 2016, at 7:18 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br>
><br>
><br>
>> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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.<br>
><br>
> Perhaps we're not doing a good job of messaging this.<br>
><br>
> 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.<br>
<br>
</span>My primary concern is that it’s easy to think you’ve done the right thing and push out a release because all of your testing shows it’s good, only to find you messed up in a way that it’s easy for a tool to validate. Writing new code is probably not going to be the primary source of this, but refactoring a `public` class to an `open` one, where there are already existing tests for that class, probably in a single file and using `@testable`, it’s easy to say, “looks good, tests passed, integrations look good.”<br></blockquote><div><br></div><div>If you're refactoring `public` classes into `open` ones, though, you'd be more likely to have forgotten to open a method you intend to make overridable, no? And there's no way to change the rules here to have `@testable` pick that up...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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.<br>
<br>
</span>Just FYI: The default Frameworks target also uses @testable for the Swift unit tests.<br>
<br>
Regardless, there are mitigations that can turn this potential (maybe it’s not even an issue in practice) test-time error into a near compile-time error (using a linter).<br>
<br>
-David<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>