On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution < [email protected]> wrote:
> > > On Jul 27, 2016, at 7:18 PM, John McCall <[email protected]> wrote: > > > > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution < > [email protected]> 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. > > 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.” > 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... > 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. > > Just FYI: The default Frameworks target also uses @testable for the Swift > unit tests. > > 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). > > -David > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
