[swift-build-dev] [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Drew Crawford]

You know... you have a really good point there.  I never even stopped to think about that assumption.

I think clearly swift-multitool should frontend, but is there a reason we don't have an independent testing tool from the package manager?

That very much does seem like the kind of architectural thing we should iron out before a proposal is accepted.  Maybe I missed an obvious rationale in the earlier discussion.

> On Jan 9, 2016, at 12:01 AM, Brian Pratt <brian at pratt.io> wrote:
> 
> It's not the approach (I'll save my commentary on that for the right thread) it's the fact that I think the build tool shouldn't be concerned with things like test output and GUI reporting. That feels like a behavior that belongs in the testing tools themselves, doesn't it?
> 
> On Friday, January 8, 2016, Drew Crawford <drew at sealedabstract.com <mailto:drew at sealedabstract.com>> wrote:
> 
>> On Jan 8, 2016, at 9:17 PM, Brian Pratt <brian at pratt.io <javascript:_e(%7B%7D,'cvml','brian at pratt.io');>> wrote:
>> 
>> I don't really think innovation is something worth sacrificing *absolute* flexibility for. Not in a tool that's primarily meant to enable developers to distribute and consume shared libraries of code. There are going to be many ways that developers prefer to write tests and something as generic as a package manager should, in my mind, allow for all of that. While I again agree that XCTest is the most sensible default, I think there's value in expressing the idea (one not called out by either this proposal or the one for third-party testing frameworks) that the build tool should not have concrete dependencies on XCTest but rather XCTest should integrate as one of many potential generic implementations usable with the build tool in the most minimal interface possible. 
>> 
>> That is to say, the build tool shouldn't take an opinion at all how tests are run, just about the general result. Enforcing any kind of uniformity is counter-intuitive as people may end up with fragmentation in their build tools themselves rather than just in their testing frameworks. There are already more than a handful of Swift testing frameworks that aren't XCTest-like, even some that are more Quickcheck-inspired, and these prescriptive testing approaches within an opinionated build tool hinder the community's ability to innovate on their own. The language and its tools should give users flexibility to allow for innovation, not try to prescribe anything about how testing should be done in order to enforce uniformity. That's a loss.
> 
> This is a nice philosophy, but what does any of it mean?
> 
> We already have "*absolute* flexibility"–SwiftPM and Foundation tests are simply an ad-hoc script.  The script can literally do anything, and report its outputs any way.  It can use any testing framework.  It can live anywhere in your repository and be named anything, and can require any number of system-installed dependencies (or not), can be written in any language that you may or may not have installed (Python seems popular, some debate if 2 or 3 <https://github.com/apple/swift-package-manager/pull/108>...), it can take any number of arguments, it can build and test together or separately, it can play music in your iTunes library.  A proposal that provided "absolute" flexibility would simply be:
> 
>> # Motivation
>> 
>> We need absolute flexibility in tests.
>> 
>> # Proposed solution
>> 
>> Anyone can write tests however the fuck they want.
> 
> Any longer proposal is *necessarily* going to define *some* limits to use of any proposed testing feature.  The question is whether some particular limit is sense or nonsense, not whether there should be anything standardized at all.  And we need to have a specific conversation around the exact technical details of the interface.
> 
> That conversation is currently ongoing on swift-build-dev.  If you think a UNIX process model (which does limit flexibility!) is superior to a protocol-based approach, I would love to read an argument for that on the thread.  It has some drawbacks we have been talking about (such as no common reporting format for CI / GUI / Xcode to consume) but maybe you have ideas for how we can solve that problem within a UNIX process model interface.
> 
> In any case, SE-0019's treatment of the interface is so incidental that I do not see why the interface question (which is in my mind still very debatable at this moment) would be a defining issue in this review.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160109/9698d243/attachment.html>