spatie Swift Testing in Bloom
Use Swift Testing for new core tests and follow neighbouring suites in Tests/BloomCoreTests.
The target imports BloomCore, not the app. Test presentation decisions in the core; use XCTest
for UI automation if that is requested. Do not migrate unrelated XCTest tests during a review.
Run ./Tools/test-core.sh <filter> for the affected suites. make test runs the whole core suite
but does not compile the app; use make build for app compilation when the change needs it.
Follow CLAUDE.md for required lint and CI checks. Keep real agent calls and machine-dependent
checks opt-in, as documented by Tools/test-core.sh.
Keep assertions about observable behaviour. Lift mutating calls out of #expect: store their
result in a local, then assert on it. Use isolated temporary files, databases and defaults domains.
For reviews, report actual defects with file locations and effects. For test changes, edit the files directly. Check installed toolchain/API availability rather than treating this guide as more authoritative than compiler diagnostics or upstream documentation.
Load only the relevant references:
- Core rules: suites, assertions and parameterised cases.
- Test design: dependencies, errors and useful regressions.
- Async tests: serialisation, completion and cancellation.
- Newer APIs: version-dependent testing features.
- XCTest migration: only for a requested migration.