https://github.com/uncommon/rundown
Swift BDD testing framework that leverages result builders and macros.
https://github.com/uncommon/rundown
Last synced: over 1 year ago
JSON representation
Swift BDD testing framework that leverages result builders and macros.
- Host: GitHub
- URL: https://github.com/uncommon/rundown
- Owner: Uncommon
- License: mit
- Created: 2024-11-18T23:57:01.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-02-28T04:27:38.000Z (over 1 year ago)
- Last Synced: 2025-02-28T11:59:31.297Z (over 1 year ago)
- Language: Swift
- Size: 195 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
## Rundown
Rundown is based on the pattern used in testing libraries such as RSpec, where tests are organized into steps:
```swift
describe("this app feature") {
context("in one context") {
it("does one thing") {
// perform tests
}
}
context("in another context") {
beforeAll {
// set up the context
}
it("does another thing") {
// perform tests
}
afterAll {
// clean up
}
}
}
```
A Swift result builder is used to assemble the steps into an object that can be executed in a unit test. The result builder also ensures proper ordering of elements:
* `beforeAll`
* `beforeEach`
* `describe`/`context`/`it`/`within`
* `afterEach`
* `afterAll`
Mis-ordered elements produce a compile-time error.
`within` is a new element type for tests that need to run inside a callback, such as `TaskLocal.withValue()`.
## Test framework support
The goals is for this library to be equally useful in either XCTest or Swift Testing.
XCTest support has the following features:
* Each test element is run using `XCTContext.runActivity()` so that the test structure is evident in the logs.
* A sub class of `XCTestCase`, named `Rundown.TestCase`, is provided so that test failures include the full name of the test element, including enclosing `Describe` and `Context` elements.
* `XCTSkip` is handled so that only the remaining elements at that level are skipped.
* Using `XCTContext.runActivity()` with `async` tests is currently not supported. It is a `@MainActor` function, which complicates things.
Similar support for Swift Testing is planned, but the Swift Testing APIs do not yet provide for implementing those features. It is still possible to simply run the test elements, though.
## Running tests
The main way to run tests looks like this:
``` swift
spec {
it("works") {
// ···
}
}
```
The `spec()` function creates an outer `describe` element, using either the name of the calling function or a provided string, and then executes it. This is a global function.
There is also an `async` version of `spec()`, so if your test function is `async` then just call `await spec { ··· }`, and then you can use `await` inside your test elements.
When working with `XCTest`, there is also `spec()` as a method of `XCTestCase` - or more precisely, a method of the subclass `Rundown.TestCase`. This subclass should always be used so that issues can be logged with the full test element description, and this version of `spec()` uses an `XCTActivity` for each test element.
The goal is to do something similar for Swift Testing, but it doesn't yet have an equivalent for `XCTActivity`.
## Goals and plans
* Compatibility with XCTest and Swift Testing, with an API that looks the same in either case
* Flexibility to use it or not for any given test (hence there is no custom test discovery; this may change in the future, especially if framework support improves)
* Minimal boilerplate at the use site
* Ease of use during development, such as running (or skipping) specific elements