<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=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I envisaged command line arguments to `swift build`. What use cases are we talking about here for making which tests run more configurable?</span></div></blockquote></div><br class=""><div class="">Well I think some kind of CLI support (like perhaps passing the whole CLI to the testing framework?) makes sense.</div></div></div></blockquote><div><br class=""></div><div>That’s our current thinking.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Specifically one problem that motivates flexibility here is the per-commit continuous integration. If my test suite is 15 minutes, and I'm going to run that in a few different configurations (32 vs 64-bit, or say we support iOS someday and I'm cross-compiling for N simulators or hardware devices, etc.) I'm in for a bad time trying to do all that every commit.</div><div class=""><br class=""></div><div class="">There are a lot of "solutions" here–parallelization, random sampling, running an abbreviated test suite ordinarily and the full test suite every 10th commit–a test suite that tries to maximize code coverage per unit time–there are all kinds of ways to look at this problem that may make sense to somebody.</div><div class=""><br class=""></div><div class="">I'm simply pushing that decision out to individual test frameworks to study. XCTest thinks you should have test suites that are human curated. That's one way to skin the cat. Let's give another test framework the flexibility to think differently on this problem.</div></div></div></blockquote><div><br class=""></div><div>Sounds super interesting. We should make sure the protocol we design can do these things.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><span style="font-family: HelveticaNeue;" class="">I’ll be working on the testing infrastructure as soon as the proposal has been reviewed. As I do so I’ll be making notes on this aspect.</span></blockquote><br class=""></div><div class="">Thanks for picking this up. Getting basic testing support in place is really important, and IMO the current proposal is really strong. I am focusing on some of these other areas not as a distraction but because I think the basic testing ideas are strong enough already that they don't need my help :-)</div></div></div></blockquote></div><br class=""></body></html>