@@ -168,4 +168,39 @@ transitively get access to it through the app itself. In Xcode, go to "Build Pha
168168"Dependencies" from the "Link Binary With Libraries" section. When using SwiftPM, remove the
169169"Dependencies" entry from the ` testTarget ` 's' ` dependencies ` array in ` Package.swift ` .
170170
171+ ### Test case leakage
172+
173+ Sometimes it is possible to have tests that pass successfully when run in isolation, but somehow fail
174+ when run together as a suite. This can happen when using escaping closures in tests, which creates
175+ an alternate execution flow, allowing a test's code to continue running long after the test has
176+ finished.
177+
178+ This can happen in any kind of test, not just when using this dependencies library. For example,
179+ each of the following test methods passes when run in isolation, yet running the whole test suite
180+ fails:
181+
182+ ``` swift
183+ final class SomeTest : XCTestCase {
184+ func testA () {
185+ Task {
186+ try await Task.sleep (for : .seconds (0.1 ))
187+ XCTFail ()
188+ }
189+ }
190+ func testB () async throws {
191+ try await Task.sleep (for : .seconds (0.15 ))
192+ }
193+ }
194+ ```
195+
196+ This happens because ` testA ` escapes some work to be executed and then finishes immediately with
197+ no failure. Then, while ` testB ` is executing, the escaped work from ` testA ` finally gets around
198+ to executing and causes a failure.
199+
200+ You can also run into this issue while using this dependencies library. In particular, you may
201+ see test a failure for accessing a `` TestDependencyKey/testValue `` of a dependency that your
202+ test is not even using. If running that test in isolation passes, then you probably have some
203+ other test accidentally leaking its code into your test. You need to check every other test in the
204+ suite to see if any of them use escaping closures causing the leakage.
205+
171206[ xctest-dynamic-overlay-gh ] : http://github.com/pointfreeco/xctest-dynamic-overlay
0 commit comments