There will be cases where modules will need a way to override or mock Subprocess execution. It can be because that module wants to customize the way that processes are launched, such as logging or accounting of them (e.g. restricting a certain number of concurrent processes). Also, there are test cases that may want to mock process execution entirely, such as providing edge case outputs, and even unusual process behaviours. Since Subprocess entry points are static and defined on the struct itself, it's hard to do these kinds of things.
Ideally, Subprocess could be a protocol so that functions and variables can pass around instances of it. See here how TSC abstracts the notion of a FileSystem as an example. We make good use of this in SwiftPM in our tests using an in-memory mocked filesystem to drive the tests for boosted performance and accuracy.
https://github.com/swiftlang/swift-tools-support-core/blob/main/Sources/TSCBasic/FileSystem.swift#L177
Alternatively, there could be a standard protocol (e.g. Subprocessable) defined in the same place where the Subprocess API resides so that everyone can agree on the same protocol.
There will be cases where modules will need a way to override or mock Subprocess execution. It can be because that module wants to customize the way that processes are launched, such as logging or accounting of them (e.g. restricting a certain number of concurrent processes). Also, there are test cases that may want to mock process execution entirely, such as providing edge case outputs, and even unusual process behaviours. Since Subprocess entry points are static and defined on the struct itself, it's hard to do these kinds of things.
Ideally, Subprocess could be a protocol so that functions and variables can pass around instances of it. See here how TSC abstracts the notion of a FileSystem as an example. We make good use of this in SwiftPM in our tests using an in-memory mocked filesystem to drive the tests for boosted performance and accuracy.
https://github.com/swiftlang/swift-tools-support-core/blob/main/Sources/TSCBasic/FileSystem.swift#L177
Alternatively, there could be a standard protocol (e.g. Subprocessable) defined in the same place where the Subprocess API resides so that everyone can agree on the same protocol.