Testing delegate actions with case key paths

[lukeredpath]

I'm currently upgrading to 1.4 and starting to take advantage of case key paths - I like the new TestStore.receive that takes a case key path as it is generally a lot more concise and most of the time the full action value is not needed as the state assertion is the one that's important.

However, I do strongly feel there is a notable exception to this and that is delegate actions - delegate actions are specifically designed to communicate with a parent and sometimes they do this by passing some value up to the parent in the delegate action's associated value. There is no meaningful way of testing these actions with a state assertion as they do not affect the state of the feature under test, but it is often important to assert that the delegate action contains the correct value.

TCA currently offers no mechanism to test this besides the .receive overload that takes an (Action) -> Bool closure. The only other approach is to keep using the old method of testing against the full action however this requires that a) your Action type remains Equatable which means b) not being able to replace the soft-deprecated TaskResult with Result.

I would like an API along the lines of store.receive(\.delegate.foo, with: fooValue) and it is possible to build such a helper on top of the built-in receive function:

extension TestStore {
    /// Allows you to assert that the test store received an action matching the given case key path with the expected nested value.
    public func receive<Value: Equatable>(
      _ actionCase: CaseKeyPath<Action, Value>,
      with expectedActionValue: Value,
      timeout duration: Duration = .zero,
      assert updateStateToExpectedResult: ((_ state: inout State) throws -> Void)? = nil,
      file: StaticString = #file,
      line: UInt = #line
    ) async where State: Equatable, Action: CasePathable {
        await self.receive(
            { action in
                guard let actualValue = action[case: actionCase] else {
                    return false
                }
                return actualValue == expectedActionValue
            },
            timeout: duration,
            assert: updateStateToExpectedResult,
            file: file,
            line: line
        )
    }
}

This works reasonably well, although the only error you can get is that an unexpected action was received. If this was built-in, it could probably handle the case where the action matches the case key path but the value does not, and provide a specific error message for this scenario (and probably just a diff of the value rather than the entire action).

[mbrandonw]

We actually did consider this style of receive when we introduced the tools for 1.4, but we ultimately decided against it because we didn't know of a compelling use case. The situation of testing delegate actions does seem pretty compelling. We will discuss more.

[randomeizer]

Have you ever considered having a DelegatingAction protocol? Something like:

public protocol DelegatingAction<DelegateAction> {
  static func delegate(_ action: DelegateAction) -> Self
}

I don't have a concrete use case where it would save me time/lines of code as yet, but it feels like something that makes sense.

[lukeredpath]

What purpose would the protocol serve? Is there some kind of algorithm or generic behaviour you could build on top of the protocol? I can't think of one.

[randomeizer]

My main thought would be to allow something like this, upstream:

public var body: some ReducerOf<Self> {
      Scope(state: \.someDelegatingFeature, action: \.someDelegatingFeature) {
        SomeDelegatingFeatureReducer()
      } onDelegate: { delegatedAction, state in
        // do something...
      }

This would be instead of just adding a new Reducer {...} after the Scope to handle delegate actions. It would mean you can explicitly just handle delegated action cases.

However, might not be worth it.

[lukeredpath]

One gotcha with this implementation - unfortunately it doesn't work when the action has multiple associated values as tuples are not equatable.

[lukeredpath]

I had a thought that multiple associated values could be handled with a number of overloads but I can't seem to get it to pick the right overload - any ideas on if this can be made to work?

public func receive<ValueOne: Equatable, ValueTwo: Equatable>(
  _ actionCase: CaseKeyPath<Action, (ValueOne, ValueTwo)>,
  with expectedActionValue: (ValueOne, ValueTwo),
  timeout duration: Duration = .zero,
  assert updateStateToExpectedResult: ((_ state: inout State) throws -> Void)? = nil,
  file: StaticString = #file,
  line: UInt = #line
) async where State: Equatable, Action: CasePathable {
    await self.receive(
        { action in
            guard let actualValue = action[case: actionCase] else {
                return false
            }
            return 
                actualValue.0 == expectedActionValue.0 &&
                actualValue.1 == expectedActionValue.1
        },
        timeout: duration,
        assert: updateStateToExpectedResult,
        file: file,
        line: line
    )
}

public func receive<ValueOne: Equatable, ValueTwo: Equatable, ValueThree: Equatable>(
  _ actionCase: CaseKeyPath<Action, (ValueOne, ValueTwo, ValueThree)>,
  with expectedActionValue: (ValueOne, ValueTwo, ValueThree),
  timeout duration: Duration = .zero,
  assert updateStateToExpectedResult: ((_ state: inout State) throws -> Void)? = nil,
  file: StaticString = #file,
  line: UInt = #line
) async where State: Equatable, Action: CasePathable {
    await self.receive(
        { action in
            guard let actualValue = action[case: actionCase] else {
                return false
            }
            return 
                actualValue.0 == expectedActionValue.0 &&
                actualValue.1 == expectedActionValue.1 &&
                actualValue.2 == expectedActionValue.2
        },
        timeout: duration,
        assert: updateStateToExpectedResult,
        file: file,
        line: line
    )
}

[lukeredpath]

if I rename the above to receiveTwo and receiveThree just to try and avoid disambiguation problems, I still get an error:

await store.receive(\.path.to.tuple, with: (one, two)) // Type of expression is ambiguous without a type annotation

[lukeredpath]

Continuing to iterate on this - for now, I've come up with an additional overload for non-equatable values that takes a matcher closure:

public func receive<Value>(
  _ actionCase: CaseKeyPath<Action, Value>,
  matching valueMatcher: (Value) -> Bool,
  timeout duration: Duration = .zero,
  assert updateStateToExpectedResult: ((_ state: inout State) throws -> Void)? = nil,
  file: StaticString = #file,
  line: UInt = #line
) async where State: Equatable, Action: CasePathable {
    await self.receive(
        { action in
            guard let actualValue = action[case: actionCase] else {
                return false
            }
            return valueMatcher(actualValue)
        },
        timeout: duration,
        assert: updateStateToExpectedResult,
        file: file,
        line: line
    )
}

This version can also be used for delegate actions that have multiple values as Swift will automatically destructure the tuple of arguments for you:

await store.receive(\.delegate.actionWithMultipleValues) { valueOne, valueTwo in
  // perform boolean test here
}

In fact, we can re-implement the original version for equatable values in terms of this one:

public func receive<Value>(
  _ actionCase: CaseKeyPath<Action, Value>,
  with expectedActionValue: Value,
  timeout duration: Duration = .zero,
  assert updateStateToExpectedResult: ((_ state: inout State) throws -> Void)? = nil,
  file: StaticString = #file,
  line: UInt = #line
) async where State: Equatable, Action: CasePathable, Value: Equatable {
    await self.receive(
        actionCase,
        matching: { $0 == expectedActionValue },
        timeout: duration,
        assert: updateStateToExpectedResult,
        file: file,
        line: line
    )
}

[3a4oT]

We hit the same problem, and it would be nice to have a built-in solution for this. Thanks for sharing the workaround @lukeredpath . cc @mbrandonw

[stephencelis]

@3a4oT This was added to the library in 1.6.0, so you should already have access to the tool if you’re on a recent version of TCA.

[3a4oT]

Thanks for the update. It seems like it works with an Equtable object only; our use case is a tuple since we have custom navigation machinery, which was implemented in the early days of TCA. For now, I used an overload provided in the current discussion.

[stephencelis]

@3a4oT You could also use a custom case key path depending on your use. For example, our IdentifiedAction and StackAction types have subscripts that allow you to do:

await store.receive(\.path[id: 0], .childAction)

Here's how it's implemented:

https://github.com/pointfreeco/swift-composable-architecture/blob/main/Sources/ComposableArchitecture/Reducer/Reducers/StackReducer.swift#L274-L282