Support for expected "crashers" #157
Labels
enhancement
New feature or request
Comments
|
Tracked internally as rdar://111625303. |
grynspan
added a commit
that referenced
this issue
Apr 10, 2024
This PR adds a new kind of expectation called an "exit test", "death test",
"expected crasher", etc. It can be invoked by writing:
```swift
fatalError("How dare you!")
}
```
It works by spinning up a second process that re-runs the same test function.
The parent process awaits the return of the child process, while the child
process executes the closure passed to `#expect()`.
This is similar to calling `fork()`, however that function is fundamentally
unusable on Darwin and unavailable on Windows, so I've pursued a different
implementation here that works across macOS, Linux, and Windows.
There are some constraints to using exit tests that are documented, but which
are not enforced at compile time. swift-syntax's `lexicalContext` should allow
us to do general checks for these constraints at compile time.
> [!WARNING]
> This is an experimental feature and is unlikely to ship in this form. It is
> not compatible with `XCTestScaffold` and can _only_ be used with the Swift 6
> toolchain/SwiftPM.
Resolves #157.
(Sort of.)
grynspan
added a commit
that referenced
this issue
Apr 10, 2024
This PR adds a new kind of expectation called an "exit test", "death test",
"expected crasher", etc. It can be invoked by writing:
```swift
fatalError("How dare you!")
}
```
It works by spinning up a second process that re-runs the same test function.
The parent process awaits the return of the child process, while the child
process executes the closure passed to `#expect()`.
This is similar to calling `fork()`, however that function is fundamentally
unusable on Darwin and unavailable on Windows, so I've pursued a different
implementation here that works across macOS, Linux, and Windows.
There are some constraints to using exit tests that are documented, but which
are not enforced at compile time. swift-syntax's `lexicalContext` should allow
us to do general checks for these constraints at compile time.
> [!WARNING]
> This is an experimental feature and is unlikely to ship in this form. It is
> not compatible with `XCTestScaffold` and can _only_ be used with the Swift 6
> toolchain/SwiftPM.
Resolves #157.
(Sort of.)
grynspan
added a commit
that referenced
this issue
Apr 10, 2024
This PR adds a new kind of expectation called an "exit test", "death
test", "expected crasher", etc. It can be invoked by writing:
```swift
#expect(exitsWith: .failure) {
fatalError("How dare you!")
}
```
It works by spinning up a second process that re-runs the same test
function. The parent process awaits the return of the child process,
while the child process executes the closure passed to `#expect()`.
This is similar to calling `fork()`, however that function is
fundamentally unusable on Darwin and unavailable on Windows, so I've
pursued a different implementation here that works across macOS, Linux,
and Windows.
There are some constraints to using exit tests that are documented, but
which are not enforced at compile time. swift-syntax's `lexicalContext`
should allow us to do general checks for (some of) these constraints at
compile time.
Resolves #157.
(Sort of.)
### Checklist:
- [x] Code and documentation should follow the style of the [Style
Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md).
- [x] If public symbols are renamed or modified, DocC references should
be updated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
It should be possible to test that some code triggers process termination with a nonzero exit code and optionally certain output to standard output and error.
Expected behavior
No response
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of
swift --version && uname -a)No response
The text was updated successfully, but these errors were encountered: