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

[Paul Cantrell]

> On Jan 5, 2016, at 4:48 PM, Max Howell <max.howell at apple.com> wrote:
> 
>>> Yes, and indeed, this isn’t really acceptable, but I think any changes to how this work would involve a discussion on the swift-build-dev mailing list. Really how targets depend on each other and external dependencies in the Package.swift manifest needs some work in general.
>> 
>> Given that you’ve already recognized the future need for more flexible test-module-specific build config, and now there’s also this concern about per-test-module dependencies, is it worth considering giving each test module its own (possibly implicit) target in Package.swift? That might kill several birds with one stone.
> 
> I’m not sure it’s worth it yet. You can’t really do anything with targets in Package.swift yet (just specify internal inter-module dependencies). I’d rather wait until the manifest format had some more functionality and had settled more, rather than slap things in without more understanding about how the manifest is going to actually be used.

Fair enough. I’d at least make sure that this proposal doesn’t interfere with doing that in the future.

(My understanding of the package manager is too shallow to make that assessment myself, so I’ll just leave the thought sitting there….)

>>> You should be running and checking the tests of your dependencies somewhat regularly.
>>> 
>>> But when developing your own software, this would be a waste of engineering time.
>> 
>> Indeed, clearly that should not be the default. In general, assuming unnecessary building to be “almost free” is a mistake.
>> …
>> However, having the option to run dependency tests seems very nice.
> 
> I agree and I wish we could force all tests to be run. But this is just idealism. Practically all of us would just start building with the “don’t do that flag”. 
> 
> I think at the least when we have a “publish” command we will run all the tests. As well as lint. In day to day development we cannot expect developers to wait, but we have a duty to ensure the packaging ecosystem we help create is as high quality as possible.

Yes, anything that slows or complicates the dev cycle will send everyone straight to “torches and pitchforks” mode, and will be the target of hacks and workarounds galore. The normal build cycle needs to be as lean as possible.

Running dependency tests by default for any sort of “publish” command seems right.

Now lint … lint I’m not sure about. It’s problematic as soon as you try to establish a standard, as we’ve already established on this list in the “mandatory self” discussion. The truth is that I don’t care about a third party lib’s weird formatting decisions nearly as much as I care about its tests passing.

Cheers,

Paul