> 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.” > 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
