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

plx plxswift at icloud.com
Fri Jan 8 07:45:11 CST 2016


One more thing:

> On Jan 6, 2016, at 1:52 PM, Max Howell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Notably: currently the tests compile to executables, so once they are built you can run them independently. I intend to keep this design, if possible.
> 

…if I am interpreting this correctly, I’m not sure I like it and I realized another issue isn’t being explicitly-addressed in the proposal:

- If there is test-only utility code, where does it live? How much visibility do the various test modules have into each other?

…and seeing that the tests are currently intended to get compiled to individual executables makes me at least a little concerned that the answer might be “they have no such mutual visibility”.

Can the document at least clarify the intended/philosophical outlook here? 

I ask b/c I’ve found that it isn’t that uncommon in certain cases to wind up with data-driven tests; e.g. the actual input-output pairs might live in some JSON/XML/whatever, and the test code just imports-and-parses them, checks your code against them, and complains about mis-matches.

At present it’s easy to create-and-use such test-specific helper code; it’s not clear if that’s the case under the proposal. 

Relatedly, I’m aware that resource-packing is currently a “future feature” for the PM itself, so I don’t begrudge it’s not being handled in this proposal; nevertheless it seems important enough to also go into a section touching on “future directions/future goals”.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/7bd06b78/attachment.html>


More information about the swift-evolution mailing list