[swift-build-dev] Proposal: SwiftPM Test Naming Conventions

[Daniel Dunbar]

> On Jul 19, 2016, at 2:32 PM, Ankit Agarwal via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> Hi,
> 
> Great to see this proposal! Looks awesome! Just have couple of doubts:
> 
> For now, make it an error to have executables or libraries under Tests (for technical reasons, a LinuxMain.swiftsource file is permitted, and indeed expected, under the Tests top-level directory). The intent is to loosen this restriction in a future proposal, to allow test-specific libraries and test executables under Tests.
> 
> 
> Is there a reason we want to not allow library modules under Tests right now? I think keeping test-specific library modules under Tests makes more sense. With the convention change in this proposal all modules that do not end in Test can just act as normal modules on which Test targets can depend on.

I think we agree, it just was orthogonal to this proposal (it is a new feature) and there are some points that need to be resolved/discussed (like what dependencies are allowed, what is impact on downstream projects, etc). Also, George had posted a similar proposal in this vein here:
  https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160704/000539.html
so it seemed reasonable to let that it be handled by a separate proposal.

The other thing here is that enhancements can always come later, but since this will break all packages with tests it seems better to get ASAP.

> And Test targets would be able to define dependency on modules under Sources or Tests folder.
> For now, make it an error to have tests under Sources. We may loosen this this restriction at some point, but would need to define what it would mean from a conceptual point of view to have tests under Sources instead of Tests.
> 
> This mean that a module name that ends in `Tests` under `Sources` (even though its not an actual test) will not be allowed. I am not sure if that should be enforced, it might be too much magic.

The reason to enforce it is that it would be really bad to allow it as a non-Tests module now, but then have future semantics make it a Tests module.

 - Daniel

> 
> 
> 
> -- 
> Ankit
> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> 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/20160720/ff855ae5/attachment.html>