Add overloads of TestStore.send that accept CaseKeyPaths

[scogeo]

Recently the ability to receive actions in a TestStore was updated to support CasePaths. This was a great improvement in ergonomics, but unfortunately the ability to send actions into the store using CasePaths is missing. This leads to a bit of a dichotomy when writing test cases when using deeply nested enums in actions.

For example, this snippet from a test case in the VoiceMemoTests reads a little weird with a mixture of CasePath syntax and standard enum construction syntax.

await store.send(.recordingMemo(.presented(.onTask)))
await store.send(.recordingMemo(.presented(.stopButtonTapped))) {
  $0.recordingMemo?.mode = .encoding
}
await store.receive(\.recordingMemo.finalRecordingTime) {
  $0.recordingMemo?.duration = 2.5
}

This PR allows this now to be written as:

await store.send(\.recordingMemo.presented.onTask)
await store.send(\.recordingMemo.presented.stopButtonTapped) {
  $0.recordingMemo?.mode = .encoding
}
await store.receive(\.recordingMemo.finalRecordingTime) {
  $0.recordingMemo?.duration = 2.5
}

This significantly improves the ergonomics of writing test cases, and also improves the readability of tests cases.

While not shown in this example, the PR also supports the ability to send associated values of enums, and is included in the test case for this feature.

[stephencelis]

@scogeo Thanks for taking the time to PR this! It's actually something we talked about, but we felt that having two ways of doing the same thing was enough reason to avoid the extra API. In the case of receive, there are payloads you can ignore:

store.receive(.response(.success(MyResponse(/* complicated payload */))))
// vs.
store.receive(\.response.success)  // no payload

Meanwhile, this is not the case with send

store.send(.textFieldChanged("Hello"))
// vs.
store.send(\.textFieldChanged)  // 🛑 can't send

Even if we allow payloads as a secondary argument, the receive has the benefit of asserting equality on just the payload while saving you from having to mark every enum Equatable, which is not always easy to do:

// Need to manipulate the `Result`'s error type to be `Equatable` and not `any Error`:
store.receive(.response(.success(MyResponse(/* complicated payload */))))

// Can simply equate on the `MyResponse` type:
store.receive(\.response.success, MyResponse(/* complicated payload */))

The send is still just an alias, since payloads aren't asserted against:

// 2 ways of doing the exact same thing? Is there a difference other than syntax?

store.send(.textFieldChanged("Hello"))

store.send(\.textFieldChanged, "Hello")

Does our line of thought make sense? Is there something we're missing?

If I really stretch my thinking, losing the nested parentheses is nice, but then would we extend this to syntax to sending actions to normal Stores? Going down that path seems a little muddy to me.

[scogeo]

@stephencelis You make some good points about the differences in motivation between send and receive. This is definitely syntactic sugar for the send case.

My motivation for submitting the PR came from refactoring a large Reducer and adding additional nested enums. It is much easier to do such refactoring when the code is written using CasePaths, rather than actual nested enums which require the nested parentheses.

And in some cases, it is not just nested parentheses, it is a completely differently style of writing the code.

For example, this snippet also from VoiceMemoTests which sends an IdentifiedAction:

await store.send(.voiceMemos(.element(id: deadbeefURL, action: .playButtonTapped))) {
  $0.voiceMemos[id: deadbeefURL]?.mode = .playing(progress: 0)
}
await store.receive(\.voiceMemos[id:deadbeefURL].delegate.playbackStarted)
await self.clock.run()

With the PR, this could then be rewritten as:

await store.send(\.voiceMemos[id:deadbeefURL].playButtonTapped) {
 $0.voiceMemos[id: deadbeefURL]?.mode = .playing(progress: 0)
}
await store.receive(\.voiceMemos[id:deadbeefURL].delegate.playbackStarted)
await self.clock.run()

This looks much more symmetric and is easier for my mind to process. So while this is definitely syntactic sugar, it adds symmetry to send and receive that is currently absent, and makes test cases easier to comprehend (and maintain) especially for deeply nested enums which are very common in test cases.

With regards to Store, I don't see the need to add the equivalent overloads. Invoking send on Store typically only happens in the context of a View which sends view specific actions which rarely consist of nested enums. The common exception being the ViewAction design pattern, which I use extensively. But the observation-beta branch has officially codified support of the ViewAction design pattern and added a @ViewAction macro to assist in embedding view actions with a send method. So even this common case will be handled in the near future.

In the end, this may just be a personal coding style preference. But I do find the asymmetry between send and receive on TestStore to be a bit jarring in actual use when writing test cases. Since Store does not have the equivalent receive method, this asymmetry will never be seen in code when using a Store so there is no need to add the equivalent functionality.

[stephencelis]

@scogeo We're definitely not opposed to the idea. Let us just think on it a bit longer.

[scogeo]

@stephencelis Sounds good.

[stephencelis]

Sorry for the hold up, but after some time to think it over we think that it makes sense to have these overloads. Thanks for taking the time to PR!