Fix a few references.

mbrandonw · mbrandonw · commit 688802ce322b · 2025-02-10T18:53:27.000-08:00
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/FAQ.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/FAQ.md
@@ -217,7 +217,7 @@ However, one does not need to have any prior experience with these concepts. The
 [dependency-management-article]: <doc:DependencyManagement>
 [sharing-state-article]: <doc:SharingState>
 [navigation-article]: <doc:Navigation>
-[testing-article]: <doc:Testing>
+[testing-article]: <doc:TestingTCA>
 [migration-1.7-article]: <doc:MigratingTo1.7>
 [migration-1.10-article]: <doc:MigratingTo1.10>
 [sync-ups-tutorial]: <doc:BuildingSyncUps>
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/GettingStarted.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/GettingStarted.md
@@ -252,7 +252,7 @@ doing much additional work.
 
 ## Testing your feature
 
-> Note: For more in-depth information on testing, see the dedicated <doc:Testing> 
+> Note: For more in-depth information on testing, see the dedicated <doc:TestingTCA> 
 article.
 
 To test use a `TestStore`, which can be created with the same information as the `Store`, but it 
@@ -464,7 +464,7 @@ let store = TestStore(initialState: Feature.State()) {
 
 That is the basics of building and testing a feature in the Composable Architecture. There are 
 _a lot_ more things to be explored. Be sure to check out the <doc:MeetComposableArchitecture> 
-tutorial, as well as dedicated articles on <doc:DependencyManagement>, <doc:Testing>, 
+tutorial, as well as dedicated articles on <doc:DependencyManagement>, <doc:TestingTCA>, 
 <doc:Navigation>, <doc:Performance>, and more. Also, the [Examples][examples] directory has 
 a bunch of projects to explore to see more advanced usages.
 
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/SharingState.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/SharingState.md
@@ -452,7 +452,7 @@ Shared state behaves quite a bit different from the regular state held in Compos
 features. It is capable of being changed by any part of the application, not just when an action is
 sent to the store, and it has reference semantics rather than value semantics. Typically references
 cause serious problems with testing, especially exhaustive testing that the library prefers (see
-<doc:Testing>), because references cannot be copied and so one cannot inspect the changes 
+<doc:TestingTCA>), because references cannot be copied and so one cannot inspect the changes 
 before and after an action is sent.
 
 For this reason, the `@Shared` property wrapper does extra work during testing to preserve a 
@@ -658,11 +658,11 @@ func basics() {
 However, if your test suite is a part of an app target, then the entry point of the app will execute
 and potentially cause an early access of `@Shared`, thus capturing a different default value than
 what is specified above. This quirk of tests in app targets is documented in
-<doc:Testing#Testing-gotchas> of the <doc:Testing> article, and a similar quirk
+<doc:TestingTCA#Testing-gotchas> of the <doc:TestingTCA> article, and a similar quirk
 exists for Xcode previews and is discussed below in <doc:SharingState#Gotchas-of-Shared>.
 
 The most robust workaround to this issue is to simply not execute your app's entry point when tests
-are running, which we detail in <doc:Testing#Testing-host-application>. This makes it so that you
+are running, which we detail in <doc:TestingTCA#Testing-host-application>. This makes it so that you
 are not accidentally execute network requests, tracking analytics, etc. while running tests.
 
 You can also work around this issue by simply setting the shared state again after initializing
@@ -1071,7 +1071,7 @@ you cannot override shared state in previews.
 
 The fix is to delay creation of the store until the entry point's `body` is executed. Further, it
 can be a good idea to also not run the `body` when in tests because that can also interfere with
-tests (as documented in <doc:Testing#Testing-gotchas>). Here is one way this can be accomplished:
+tests (as documented in <doc:TestingTCA#Testing-gotchas>). Here is one way this can be accomplished:
 
 ```swift
 import ComposableArchitecture
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/StackBasedNavigation.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/StackBasedNavigation.md
@@ -350,7 +350,7 @@ with the parent.
 ## Testing
 
 A huge benefit of using the tools of this library to model navigation stacks is that testing becomes 
-quite easy. Further, using "non-exhaustive testing" (see <doc:Testing#Non-exhaustive-testing>) can 
+quite easy. Further, using "non-exhaustive testing" (see <doc:TestingTCA#Non-exhaustive-testing>) can 
 be very useful for testing navigation since you often only want to assert on a few high level 
 details and not all state mutations and effects.
 
@@ -537,11 +537,11 @@ other in a navigation stack.
 However, the more complex the features become, the more cumbersome testing their integration can be.
 By default, ``TestStore`` requires us to be exhaustive in our assertions. We must assert on how
 every piece of state changes, how every effect feeds data back into the system, and we must make
-sure that all effects finish by the end of the test (see <doc:Testing> for more info).
+sure that all effects finish by the end of the test (see <doc:TestingTCA> for more info).
 
 But ``TestStore`` also supports a form of testing known as "non-exhaustive testing" that allows you
 to assert on only the parts of the features that you actually care about (see 
-<doc:Testing#Non-exhaustive-testing> for more info).
+<doc:TestingTCA#Non-exhaustive-testing> for more info).
 
 For example, if we turn off exhaustivity on the test store (see ``TestStore/exhaustivity``) then we
 can assert at a high level that when the increment button is tapped twice that eventually we receive
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/TestingTCA.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/TestingTCA.md
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Articles/TreeBasedNavigation.md b/Sources/ComposableArchitecture/Documentation.docc/Articles/TreeBasedNavigation.md
@@ -512,7 +512,7 @@ the child domain without explicitly communicating with the parent.
 ## Testing
 
 A huge benefit of properly modeling your domains for navigation is that testing becomes quite easy.
-Further, using "non-exhaustive testing" (see <doc:Testing#Non-exhaustive-testing>) can be very 
+Further, using "non-exhaustive testing" (see <doc:TestingTCA#Non-exhaustive-testing>) can be very 
 useful for testing navigation since you often only want to assert on a few high level details and 
 not all state mutations and effects.
 
@@ -626,11 +626,11 @@ other.
 However, the more complex the features become, the more cumbersome testing their integration can be.
 By default, ``TestStore`` requires us to be exhaustive in our assertions. We must assert on how
 every piece of state changes, how every effect feeds data back into the system, and we must make
-sure that all effects finish by the end of the test (see <doc:Testing> for more info).
+sure that all effects finish by the end of the test (see <doc:TestingTCA> for more info).
 
 But ``TestStore`` also supports a form of testing known as "non-exhaustive testing" that allows you
 to assert on only the parts of the features that you actually care about (see 
-<doc:Testing#Non-exhaustive-testing> for more info).
+<doc:TestingTCA#Non-exhaustive-testing> for more info).
 
 For example, if we turn off exhaustivity on the test store (see ``TestStore/exhaustivity``) then we
 can assert at a high level that when the increment button is tapped twice that eventually we receive
diff --git a/Sources/ComposableArchitecture/Documentation.docc/ComposableArchitecture.md b/Sources/ComposableArchitecture/Documentation.docc/ComposableArchitecture.md
@@ -49,7 +49,7 @@ day-to-day when building applications, such as:
 
 - <doc:GettingStarted>
 - <doc:DependencyManagement>
-- <doc:Testing>
+- <doc:TestingTCA>
 - <doc:Navigation>
 - <doc:SharingState>
 - <doc:Performance>
@@ -70,7 +70,7 @@ day-to-day when building applications, such as:
 ### Testing
 
 - ``TestStore``
-- <doc:Testing>
+- <doc:TestingTCA>
 
 ### Integrations
 
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Extensions/Deprecations/StoreDeprecations.md b/Sources/ComposableArchitecture/Documentation.docc/Extensions/Deprecations/StoreDeprecations.md
@@ -15,4 +15,4 @@ instead.
 
 ### UIKit integration
 
-- ``ifLet(then:else:)``
+- ``Store/ifLet(then:else:)``
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Extensions/Effect.md b/Sources/ComposableArchitecture/Documentation.docc/Extensions/Effect.md
@@ -14,7 +14,7 @@
 
 - ``cancellable(id:cancelInFlight:)``
 - ``cancel(id:)``
-- ``withTaskCancellation(id:cancelInFlight:operation:)``
+- ``ComposableArchitecture/withTaskCancellation(id:cancelInFlight:isolation:operation:)``
 - ``_Concurrency/Task/cancel(id:)``
 
 ### Composition
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Extensions/Reducer.md b/Sources/ComposableArchitecture/Documentation.docc/Extensions/Reducer.md
@@ -135,7 +135,7 @@ struct CounterFeature: Reducer {
 > Note: This sample emulates a timer by performing an infinite loop with a `Task.sleep` inside. This
 > is simple to do, but is also inaccurate since small imprecisions can accumulate. It would be
 > better to inject a clock into the feature so that you could use its `timer` method. Read the
-> <doc:DependencyManagement> and <doc:Testing> articles for more information.
+> <doc:DependencyManagement> and <doc:TestingTCA> articles for more information.
 
 That is the basics of implementing a feature as a conformance to ``Reducer``. 
 
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Extensions/StoreState.md b/Sources/ComposableArchitecture/Documentation.docc/Extensions/StoreState.md
@@ -6,4 +6,3 @@
 
 - ``Store/state-20w4g``
 - ``Store/state-2wgiw``
-- ``Store/state-1qxwl``
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/03-SyncUpForm/TestingSyncUpForm.tutorial b/Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/03-SyncUpForm/TestingSyncUpForm.tutorial
@@ -101,7 +101,7 @@
       }
       
       There are two ways one can fix this test. You can use the library's "non-exhaustive" testing
-      tools (see <doc:Testing#Non-exhaustive-testing> for more info), which allows you to assert
+      tools (see <doc:TestingTCA#Non-exhaustive-testing> for more info), which allows you to assert
       on only the bits of state you care about. That can be handy, but we don't feel it is 
       appropriate in such a simple feature like `SyncUpForm`. We think non-exhaustive testing is 
       best saved for testing the integration of features, and that exhaustive testing is best for
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/04-PresentingSyncUpForm/TestingSyncUpFormPresentation.tutorial b/Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/04-PresentingSyncUpForm/TestingSyncUpFormPresentation.tutorial
@@ -211,7 +211,7 @@
       This means in non-exhaustive test stores you do not have make any mutations in the trailing
       closure if you do not want to. And anything you _do_ set in the trailing closure must match
       what was already there in order for the test to pass. See the dedicated article 
-      <doc:Testing#Non-exhaustive-testing> for more information.
+      <doc:TestingTCA#Non-exhaustive-testing> for more information.
       
       @Step {
         Emulate the user making edits to the sync-up, but again do not provide a trailing closure.
diff --git a/Sources/ComposableArchitecture/Documentation.docc/Tutorials/MeetTheComposableArchitecture/02-Navigation/03-TestingPresentation/02-03-TestingPresentation.tutorial b/Sources/ComposableArchitecture/Documentation.docc/Tutorials/MeetTheComposableArchitecture/02-Navigation/03-TestingPresentation/02-03-TestingPresentation.tutorial
@@ -25,7 +25,7 @@
         as the reducer that is being tested.
         
         > Note: See <doc:01-03-TestingYourFeature> for a tutorial on testing, as well as the article
-        <doc:Testing> for more detailed information.
+        <doc:TestingTCA> for more detailed information.
         
         @Code(name: "ContactsFeatureTests.swift", file: 02-03-01-code-0001.swift)
       }
@@ -183,7 +183,7 @@
       manner, especially when testing the integration of many features, such as is the case with
       features performing navigation.
       
-      See <doc:Testing#Non-exhaustive-testing> for more information on non-exhaustive testing
+      See <doc:TestingTCA#Non-exhaustive-testing> for more information on non-exhaustive testing
       techniques.
     }
     
diff --git a/Sources/ComposableArchitecture/TestStore.swift b/Sources/ComposableArchitecture/TestStore.swift
@@ -14,7 +14,7 @@ import IssueReporting
 /// of the way you must assert exactly how state changed, and how effect emissions were fed back
 /// into the system.
 ///
-/// See the dedicated <doc:Testing> article for detailed information on testing.
+/// See the dedicated <doc:TestingTCA> article for detailed information on testing.
 ///
 /// ## Exhaustive testing
 ///
@@ -512,7 +512,7 @@ public final class TestStore<State, Action> {
 
   /// Creates a test store with an initial state and a reducer powering its runtime.
   ///
-  /// See <doc:Testing> and the documentation of ``TestStore`` for more information on how to best
+  /// See <doc:TestingTCA> and the documentation of ``TestStore`` for more information on how to best
   /// use a test store.
   ///
   /// - Parameters:
@@ -1044,7 +1044,7 @@ extension TestStore where State: Equatable {
   /// to differ from the current state of the test store, a test failure will be triggered.
   ///
   /// This tool is most useful in non-exhaustive test stores (see
-  /// <doc:Testing#Non-exhaustive-testing>), which allow you to assert on a subset of the things
+  /// <doc:TestingTCA#Non-exhaustive-testing>), which allow you to assert on a subset of the things
   /// happening inside your features. For example, you can send an action in a child feature
   /// without asserting on how many changes in the system, and then tell the test store to
   /// ``finish(timeout:fileID:file:line:column:)-klnc`` by executing all of its effects, and finally

Original file line number	Diff line number	Diff line change
`@@ -15,4 +15,4 @@ instead.`
`15`	`15`
`16`	`16`	`### UIKit integration`
`17`	`17`
`18`		-- ``ifLet(then:else:)``
	`18`	+- ``Store/ifLet(then:else:)``