[swift-build-dev] protocol for third-party testing frameworks

[Max Howell]

>> I envisaged command line arguments to `swift build`. What use cases are we talking about here for making which tests run more configurable?
> 
> Well I think some kind of CLI support (like perhaps passing the whole CLI to the testing framework?) makes sense.

That’s our current thinking.

> 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.
> 
> 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.
> 
> 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.

Sounds super interesting. We should make sure the protocol we design can do these things.

>> 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.
> 
> 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 :-)

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