[swift-evolution] [swift-build-dev] [Review] SE-0019 Swift Testing (Package Manager)

[Brent Royal-Gordon]

> This ship has sailed: it is the present policy to make perfect the enemy of the good, or, as others word it:
> 
>>  it doesn't usually make sense to add features that we consider actively/potentially harmful, even if that solves some current short term pain.
> 
> I don't necessarily agree with the policy but I do think it should be consistently applied.  If we know we're going to refactor the XCTest interface later we shouldn't implement it the wrong way now, or else we should implement everything the wrong way now if it solves a present short-term pain, but there is nothing unique about the testing feature that does not equally apply to other situations.

I don't think the situations are the same. Quickly skimming that thread, it seems like people are arguing that the proposed feature is a step in the wrong direction. (I don't know enough to say if I agree with them; I'm simply characterizing their position.) But if you think testing support in SwiftPM is a good idea, then going from "no testing" to "XCTest-only testing" is not a step in the wrong direction, it's a step in the *right* one. Some of the design and code from the XCTest-only solution will live on in a more general one; in fact, generalizing the test harness is a straightforward extension of it.

Remember, the Swift project favors incremental development. <https://swift.org/contributing/#incremental-development> A tightly-coupled test harness is an incremental step towards a loosely-coupled test harness. That's a very different case from a workaround that does not bring us closer to a permanent solution. 

-- 
Brent Royal-Gordon
Architechies