Repository navigation
DeallocTests 4.0 (4/5): configuration, warning severity and grace period - #28
Open
DanielCech wants to merge 5 commits into
Open
DanielCech wants to merge 5 commits into
DanielCech wants to merge 5 commits into
Conversation
`DeallocationConfiguration` (timeout, severity, grace period) is set per Swift Testing test or suite with traits, and in XCTest with `withDeallocationConfiguration` around a test's code or `invokeTest()`. `timeout` stays a parameter of `expectDeallocation` because it describes the object; the rest is configuration only. An object is checked with the configuration in effect where it was tracked. `.deallocationIssues(.warning)` reports leaks without failing the test, for adopting dealloc tests in an existing project. An object still alive at the timeout is watched for a grace period (3 s); if it goes away then, it's reported as bounded retention, a warning, instead of a leak. Passing checks never wait for it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This was referenced Oct 5, 2026
Two tests asserted on wall-clock time and failed on a loaded CI runner (6.2 s and 1.9 s against a 1 s limit). The suite timeout test already proves the 100 ms timeout through the failure message, so its clock check goes. The rule that warnings skip the grace period is now `DeallocationConfiguration.effectiveGracePeriod`, which the tracker uses and the test checks directly. CI also runs the tests with the latest Xcode, so the Swift 6.3 warning path (Issue.record(severity:)) is compiled and tested. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Trackers incorrectly apply the first object’s configuration to every tracked object, and warning emission lacks effective assertions.
Review effort: Balanced
Findings: 1
Open (2)
What changed in this PR
Adds configurable deallocation timeouts, warning severity, and grace-period handling across Swift Testing and XCTest.
Changes:
- Adds task-local configuration and Swift Testing traits.
- Reports leaks as warnings and distinguishes late releases from leaks.
- Expands configuration, reporting, and CI coverage.
| File | Description |
|---|---|
.github/workflows/ci.yml |
Tests the Swift 6.3 warning path. |
Sources/DeallocTests/Diagnostics/LeakReport.swift |
Adds grace-period and late-release messages. |
Sources/DeallocTests/Expectation/DeallocationConfiguration.swift |
Defines configuration APIs and traits. |
Sources/DeallocTests/Expectation/DeallocationTracker.swift |
Applies timeout, grace-period, and severity policies. |
Sources/DeallocTests/Expectation/ExpectDeallocation.swift |
Uses configured default timeouts. |
Sources/DeallocTests/Expectation/ExpectDeallocation+DependencyInjection.swift |
Applies configuration to DI checks. |
Sources/DeallocTests/Expectation/IssueReporting.swift |
Adds warning-level reporting. |
Sources/DeallocTests/Expectation/TrackForDeallocation.swift |
Documents configuration capture. |
Tests/DeallocTestsTests/ConfigurationTests.swift |
Tests configuration precedence. |
Tests/DeallocTestsTests/ExpectDeallocationTests.swift |
Shortens configured tracking timeout. |
Tests/DeallocTestsTests/GracePeriodTests.swift |
Tests grace-period behavior. |
Tests/DeallocTestsTests/LeakReportTests.swift |
Tests new diagnostic messages. |
Tests/DeallocTestsTests/TrackForDeallocationXCTests.swift |
Covers XCTest configuration behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
# Conflicts: # Sources/DeallocTests/Expectation/IssueReporting.swift
- Each tracked object keeps the configuration in effect where it was tracked (timeout, grace period, severity). The tracker used the first object's configuration for all of them, so objects tracked in a different configuration scope were checked with the wrong values. One polling loop now checks every object against its own deadlines. - The warning tests assert that a warning is emitted with the expected message: in Swift Testing through withKnownIssue matching severity .warning (Swift 6.3+), in XCTest through an XCTestObservation that records expected failures. Before, they only checked that the test didn't fail. - The throwing-test tracking check uses a 100 ms timeout like its neighbours. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
DanielCech
added this pull request to stack #30
October 9, 2026 08:03
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Part 4 of 5. DeallocTests 4.0 series (merge in order): #25 groundwork → #26
expectDeallocation→ #27 tracking, hints, DI → #28 configuration → #29 remove legacy, docs. Why 4.0, the breaking changes and the alternatives we looked at: see #25.Configuration for a test, a suite or an XCTest class: timeout, leaks as warnings, and a grace period that tells "released late" from "leaked".
Why
timeout:to every call is noise.Taskafter its screen closes, an object can go away just after the timeout. That's bounded retention, not a leak, and flaky failures erode trust in the tests.What changes
timeoutdescribes the object, soexpectDeallocationstill takes it; severity and grace period are policies, so they're configuration only.Issue.record(severity: .warning)on Swift 6.3+, an intermittent known issue before..deallocationGracePeriod(.zero)turns it off.How to review
Expectation/DeallocationConfiguration.swiftwithDeallocationConfigurationExpectation/DeallocationTracker.swiftExpectation/IssueReporting.swiftDiagnostics/LeakReport.swiftSource +221, tests +245. The grace period is the most optional piece of the series; it can be split out or dropped without affecting the rest.
Testing
ConfigurationTests(call vs test vs suite precedence, nested trait order),GracePeriodTests, XCTest configuration cases. No test asserts on wall-clock time, so they hold on a loaded runner. Green on macOS (both trait settings) and the iOS Simulator; a CI job on the latest Xcode compiles and tests the Swift 6.3 warning path (Issue.record(severity:)).🤖 Generated with Claude Code