[SwiftPM] [Proposal Draft] Add support for test-only dependencies

thislooksfun · January 9, 2017, 4:52am

Hello swift-build-dev,

I have written up a first draft of a proposal to (re-) add a `testDependencies` section to `Package.swift`.
Please let me know what you think / how to improve it.

github.com

thislooksfun/swift-evolution/blob/master/proposals/NNNN-swiftpm-test-only-dependencies.md

# Feature name

* Proposal: [SE-NNNN](NNNN-swiftpm-test-only-dependencies.md)
* Authors: [thislooksfun](https://github.com/thislooksfun)
* Review Manager: TBD
* Status: **Awaiting review**

## Introduction

This proposal seeks to add a natively supported way to use some external packages for use only when running tests through Swift Package Manager (SwiftPM)

Swift-evolution thread: [\[swift-evolution\] \[SwiftPM\] Proposal: Add support for test-only	dependencies](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161226/029720.html)

## Motivation

Currently, using any external package only when testing is technically possible, but it is roundabout and not very clean or intuitive, especially when running tests manually, whether through the CLI or XCode.

The current method in use by many projects ([1][test-example-1], [2][test-example-2], [3][test-example-3], [4][test-example-4]) is to have an entirely separate `Package.swift`, commonly titled `.Package.test.swift`, which is then swapped out to replace `Package.swift` during testing. This is both cumbersome and can easily lead to confusion and failing tests if dependencies fail to be added to both files, or if the two are not swapped before, or after, running tests.

Further motivation: this was originally intended to be in SwiftPM - [it was even implemented, but was removed after it stopped working and nobody fixed it.](https://github.com/apple/swift-package-manager/commit/34b7826cb586b0769ea5f60a7718d7de599ce27f)

This file has been truncated. show original

Thanks,
-thislooksfun (tlf)

Aciid · January 9, 2017, 9:32am

Hi,

Thanks for driving this! Comments inline:

The actual implementation of testDependencies will be nearly identical to the existing dependencies section. All the same subtypes can be used in either, and the syntax is exactly the same for both. The sole difference is that when running swift build, the testDependencies is ignored completely, but when running swift test, all the packages listed in testDependencies are effectively added to the dependencies list before compiling and testing occurs.

Package.swift example with testDependencies:

import PackageDescription
let package = Package(
    name: "ExamplePackage",
    dependencies: [
      .Package(url: "https://github.com/user1/package1.git", majorVersion: 2),
      .Package(url: "https://github.com/user2/package2.git", majorVersion: 1, minor: 4),
    ],
    testDependencies: [
      .Package(url: "https://github.com/user3/test-package.git", majorVersion: 3),
    ]
)
In the above example example, running swift build would build the package ExamplePackage, including user1/package1 and user2/package2, but not user3/test-package.

Running swift test, on the other hand, would build and test the package ExamplePackage, while including user1/package1 and user2/package2, and user3/test-package.

Once the product proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md> is implemented it will be possible for individual targets to depend on products vended by external dependencies, and packages to vend fine grained targets (as products). That means we can create this feature such that a regular (non-test) target can also depend on a product coming from one of the testDependencies as long as that target is not vended to public via the new product API.
This could be a useful thing to have, consider swiftpm itself, it has an executable target called TestSupportExecutable which contains tests which needs to be run outside of the current binary. SwiftPM would probably never vend this as a product to outside world but that target should be able to use testDependencies (like Quick/Nimble).
This is a test related usecase but there could be non-test usecases. This is why instead of testDependencies I prefer localDependencies for this feature.

Thoughts?