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

[Drew Crawford]

Please take the lead on this.

For background.  We required a solution around the time I was working on this originally, and given that upstream wasn't ready (which is understandable) we decided to go alone, and we're now committed to our solution.  So from our POV the problem has been solved.

> On Mar 16, 2016, at 8:12 PM, Max Howell <max.howell at apple.com> wrote:
> 
> It’s time to resurrect this proposal.
> 
> By all means let’s talk a bit more here, but I hope Drew will submit a proposal, or if he doesn’t have the time I can write it up, co-authored and we’ll submit to evolution.
> 
>> On Jan 12, 2016, at 5:02 PM, Max Howell <max.howell at apple.com <mailto:max.howell at apple.com>> wrote:
>> 
>> To follow up here, I’d like to put this particular proposal on the back burner for a couple weeks until we have the initial testing infrastructure in place.
>> 
>> We should keep this proposal in mind as we build the testing infrastructure, as this protocol is in my mind at least, the more important of the two.
>> 
>>> On Jan 6, 2016, at 11:58 AM, Max Howell via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>>> 
>>>>> 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 :-)
>>> 
>>>  _______________________________________________
>>> swift-build-dev mailing list
>>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
> 

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