[swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[Xiaodi Wu]

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
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160727/9cee79de/attachment.html>