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

David Owens II david at owensd.io
Fri Jan 8 21:20:33 CST 2016

> On Jan 8, 2016, at 5:54 PM, Drew Crawford <drew at sealedabstract.com> wrote:
> I don't believe this is the case either.  Under this proposal, building and running is coupled at the CLI, but introducing new CLI arguments is not any great hardship. 
> It may help to clearly identify the coupling you mean, and how this proposal very specifically establishes it.  Everybody agrees that "coupling is bad, kids" but not everyone understands how this proposal brings it into being.
> I wonder if your objection is simply that the XCTest proposal hit review first, rather than the third-party frameworks proposal.  That is only because the XCTest folks are simply better motivated to draft it: there is tons of existing code that can benefit, the test framework actually exists, etc.  The third-party frameworks are not as well-motivated.

I don’t care that the default and only supported test runner is XCTest for the moment. I can simply write a little wrapper and shell out to some other test runner. I can even get through the fact that tests will be built everytime (they won’t though, because people will simply comment them out in the Package.swift file until they are ready to use them).

What I care about is the coupling of the test phase with the build phase. I cannot work around that. 

When I run “swift build -t” or “swift tests” or whatever the CLI will be, I need to be able to do that without re-triggering builds. A no-op build is not sufficient. If you don’t agree with, then I really have no other examples to provide that can convince anyone of that fact.

At some later date, maybe we’ll get “swift build --run-tests” or “swift tests --no-build” that simply runs the tests without attempting to do a build. Ok, maybe we will. If it’s a week later, ok. If it’s a month later, ok. If it’s going to be a year away, that becomes a real issue. However, there is no compelling reason to couple this from the start, especially if there is no architectural considerations to worry about.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160108/5c146556/attachment.html>

More information about the swift-build-dev mailing list