<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">You know... you have a really good point there. &nbsp;I never even stopped to think about that assumption.<div class=""><br class=""></div><div class="">I think clearly swift-multitool should frontend, but is there a reason we don't have an independent testing tool from the package manager?</div><div class=""><br class=""></div><div class="">That very much does seem like the kind of architectural thing we should iron out before a proposal is accepted. &nbsp;Maybe I missed an obvious rationale in the earlier discussion.<div class=""><div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 9, 2016, at 12:01 AM, Brian Pratt &lt;<a href="mailto:brian@pratt.io" class="">brian@pratt.io</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">It's not the approach (I'll save my commentary on that for the right thread)&nbsp;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?<span class=""></span><div class=""><div class=""><div class=""><br class="">On Friday, January 8, 2016, Drew Crawford &lt;<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>&gt; wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 9:17 PM, Brian Pratt &lt;<a href="javascript:_e(%7B%7D,'cvml','brian@pratt.io');" target="_blank" class="">brian@pratt.io</a>&gt; wrote:</div><br class=""><div class=""><span style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">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.<span class="">&nbsp;</span></span><br style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">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.</span></div></blockquote></div><br class=""><div class="">This is a nice philosophy, but what does any of it mean?</div><div class=""><br class=""></div><div class="">We already have "*absolute* flexibility"–SwiftPM and Foundation tests are simply an ad-hoc script.&nbsp; The script can literally do anything, and report its outputs any way.&nbsp; It can use any testing framework.&nbsp; 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,&nbsp;<a href="https://github.com/apple/swift-package-manager/pull/108" target="_blank" class="">some debate if 2 or 3</a>...), it can take any number of arguments, it can build and test together or separately, it can play music in your iTunes library.&nbsp; A proposal that provided "absolute" flexibility would simply be:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""># Motivation</blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">We need absolute flexibility in tests.</blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div class=""># Proposed solution</div><div class=""><br class=""></div><div class="">Anyone can write tests however the fuck they want.</div></blockquote><br class=""><div class="">Any longer proposal is *necessarily* going to define *some* limits to use of any proposed testing feature.&nbsp; The question is whether some particular limit is sense or nonsense, not whether there should be anything standardized at all.&nbsp; And we need to have a specific conversation around the <b class="">exact</b>&nbsp;technical details of the interface.</div><div class=""><br class=""></div><div class="">That conversation is currently ongoing on swift-build-dev.&nbsp; 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.&nbsp; 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.</div><div class=""><br class=""></div><div class="">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.</div></div></blockquote></div></div></div>
</div></blockquote></div><br class=""></div></div></div></div></body></html>