[swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability
xiaodi.wu at gmail.com
Wed Jul 27 22:52:59 CDT 2016
On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:
> > On Jul 27, 2016, at 7:18 PM, John McCall <rjmccall at apple.com> wrote:
> >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution <
> swift-evolution at 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- at 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
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).
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution