[swift-evolution] [swift-build-dev] [Review] SE-0019 Swift Testing (Package Manager)
drew at sealedabstract.com
Fri Jan 8 22:28:00 CST 2016
> On Jan 8, 2016, at 9:20 PM, David Owens II <david at owensd.io> wrote:
> 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.
I think the common case (perhaps it is uncommon for you) is a test-driven implementation loop, where somebody has a failing test, they are working in a text editor or IDE, and they want to know if it the thing they changed caused the tests to pass. This is my workflow when I PR something to Foundation or SwiftPM, and my workflow on other projects.
Certainly that could be accomplished via chaining commands instead (e.g. "swift build && swift test") which better supports your workflow although that is slightly more awkward for the common situation.
But in any case this whole argument feels to me like a bikeshed–we have infinite freedom to support any number of CLI commands, with builds & tests together, separated, in a box, with a fox. This one was elected to support a common workflow, not to the exclusion of all the other things we could do additionally.
But there is language being used on this point (from several people) like:
> there is no compelling reason to couple this from the start
> My biggest concern with this proposal, as it stands, is that it isn't considering what I think are some very important details that will shape the way the build-tool works longer-term.
> For example, before any meaningful work can be done to support different types of test runners, the work is going to need to done to break the build & run tests coupling. In this way, I think the proposal does a disservice because it’s not laying a good foundation to build on, it’s laying a foundation that we already know needs to be broken up.
I fail to understand how the election of one (first) command line argument has any of these follow-on consequences at all. We are discussing a CLI frontend, not an architecture diagram.
If someone believes we are in danger of laying a bad foundation then that is an important objection, but to understand it we need an argument of the form
1. "swift build -t"
3. Therefore, [specific irreversible harm]
Until that is laid out in a way I can follow, I can't make sense of the objection.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution