Skip to content

Commit 0e0b84a

Browse files
mbrandonwp4checo
authored andcommitted
Small docs fixes.
(cherry picked from commit 8a75b24f88fe6526add8326c7c2dcc301162bd3b)
1 parent 8102f37 commit 0e0b84a

File tree

3 files changed

+9
-10
lines changed

3 files changed

+9
-10
lines changed

Sources/ComposableArchitecture/Documentation.docc/Articles/Testing.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,7 @@ class CounterTests: XCTestCase {
7474
> Tip: Test cases that use ``TestStore`` should be annotated as `@MainActor` and test methods should
7575
be marked as `async` since most assertion helpers on ``TestStore`` can suspend.
7676

77-
Test stores have a ``TestStore/send(_:_:file:line:)-3pf4p`` method, but it behaves differently from
77+
Test stores have a ``TestStore/send(_:_:file:line:)-6s1gq`` method, but it behaves differently from
7878
stores and view stores. You provide an action to send into the system, but then you must also
7979
provide a trailing closure to describe how the state of the feature changed after sending the
8080
action:
@@ -95,7 +95,7 @@ await store.send(.incrementButtonTapped) {
9595
}
9696
```
9797

98-
> The ``TestStore/send(_:_:file:line:)-3pf4p`` method is `async` for technical reasons that we do
98+
> The ``TestStore/send(_:_:file:line:)-6s1gq`` method is `async` for technical reasons that we do
9999
not have to worry about right now.
100100

101101
If your mutation is incorrect, meaning you perform a mutation that is different from what happened
@@ -146,7 +146,7 @@ await store.send(.decrementButtonTapped) {
146146
> by one, but we haven't proven we know the precise value of `count` at each step of the way.
147147
>
148148
> In general, the less logic you have in the trailing closure of
149-
> ``TestStore/send(_:_:file:line:)-3pf4p``, the stronger your assertion will be. It is best to use
149+
> ``TestStore/send(_:_:file:line:)-6s1gq``, the stronger your assertion will be. It is best to use
150150
> simple, hard coded data for the mutation.
151151
152152
Test stores do expose a ``TestStore/state`` property, which can be useful for performing assertions
@@ -160,7 +160,7 @@ store.send(.incrementButtonTapped) {
160160
XCTAssertTrue(store.state.isPrime)
161161
```
162162
163-
However, when inside the trailing closure of ``TestStore/send(_:_:file:line:)-3pf4p``, the
163+
However, when inside the trailing closure of ``TestStore/send(_:_:file:line:)-6s1gq``, the
164164
``TestStore/state`` property is equal to the state _before_ sending the action, not after. That
165165
prevents you from being able to use an escape hatch to get around needing to actually describe the
166166
state mutation, like so:

Sources/ComposableArchitecture/Documentation.docc/Extensions/TestStore.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13,14 +13,14 @@
1313

1414
### Testing a reducer
1515

16-
- ``send(_:_:file:line:)-3pf4p``
16+
- ``send(_:_:file:line:)-6s1gq``
1717
- ``receive(_:timeout:_:file:line:)``
1818
- ``finish(timeout:file:line:)``
1919
- ``TestStoreTask``
2020

2121
### Accessing state
2222

23-
While the most common way of interacting with a test store's state is via its ``send(_:_:file:line:)-3pf4p`` and ``receive(_:timeout:_:file:line:)`` methods, you may also access it directly throughout a test.
23+
While the most common way of interacting with a test store's state is via its ``send(_:_:file:line:)-6s1gq`` and ``receive(_:timeout:_:file:line:)`` methods, you may also access it directly throughout a test.
2424

2525
- ``state``
2626

Sources/ComposableArchitecture/TestStore.swift

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -224,7 +224,7 @@ public final class TestStore<State, Action, ScopedState, ScopedAction, Environme
224224

225225
/// The current state.
226226
///
227-
/// When read from a trailing closure assertion in ``send(_:_:file:line:)-3pf4p`` or
227+
/// When read from a trailing closure assertion in ``send(_:_:file:line:)-6s1gq`` or
228228
/// ``receive(_:timeout:_:file:line:)``, it will equal the `inout` state passed to the closure.
229229
public var state: State {
230230
self.reducer.state
@@ -233,8 +233,7 @@ public final class TestStore<State, Action, ScopedState, ScopedAction, Environme
233233
/// The timeout to await for in-flight effects.
234234
///
235235
/// This is the default timeout used in all methods that take an optional timeout, such as
236-
/// ``send(_:_:file:line:)-3pf4p``, ``receive(_:timeout:_:file:line:)`` and
237-
/// ``finish(timeout:file:line:)``.
236+
/// ``receive(_:timeout:_:file:line:)`` and ``finish(timeout:file:line:)``.
238237
public var timeout: UInt64
239238

240239
private var _environment: Box<Environment>
@@ -935,7 +934,7 @@ extension TestStore {
935934
}
936935
}
937936

938-
/// The type returned from ``TestStore/send(_:_:file:line:)-3pf4p`` that represents the lifecycle
937+
/// The type returned from ``TestStore/send(_:_:file:line:)-6s1gq`` that represents the lifecycle
939938
/// of the effect started from sending an action.
940939
///
941940
/// You can use this value in tests to cancel the effect started from sending an action:

0 commit comments

Comments
 (0)