Simplified TestStore ?

[larromba]

Dear TCA community,

In our production code, we've been finding the TestStore essential, however there are often cases where we'd like to ignore intermediate actions & state changes, and simply test that invoking an action produces a desired end-state. This starts to manifest in larger & more complex reducers, whereby we may write a number of tests for a single action, and must replicate the intermediate state changes in each test.

In short, is it (or will it ever be) possible with the current TestStore to invoke an action, and only test the end-state?

For example, something like this would be great:

store.send(.foo, ignoreIntermediateSteps: true) {
    $0.state = .bar // the end state
}

Rather than:

store.send(.foo) {
    // intermediate state changes
}
store.receive(...) { // intermediate action
    // intermediate state changes
}
store.receive(...) { // intermediate action
    // intermediate state changes
}
store.receive(...) {
    $0.state = .bar // the end state
}

Whilst I can see the many benefits of always testing the action & state changes in the latter example, I think there can also be benefits to just verifying the end-state. Perhaps it could be argued this issue signifies our reducer design could be improved (e.g. by breaking them into smaller & more testable components), but refactoring reducers in production code may not always be viable (due to business requirements / timescales etc). So in this sense, having the option to write some simpler / more readable tests would be preferable over maintaining complex and replicated test-code.

Thanks

[krzysztofzablocki]

I've blogged and open sourced a non-exhaustive version of TestStore I've build for my team

[larromba]

This looks great - thanks! I've forwarded it on to the relevant team.

Let's hope the TCA developers take some inspiration from this.

[stephencelis]

The article's prompted a lot of conversation! Sorry for missing this discussion earlier.

We'll definitely explore things when we have a chance. I think one thing we'll want to contend with is that though exhaustiveness can become more of a pain for tests that are more complex (e.g. tests that test how multiple layers of features integrate), and can see a lot of churn, we've also found and heard from others that exhaustiveness still helps find bugs at this level.

Of course, none of that matters if a team decides not to write tests at this layer at all, so we see that introducing a "dial" for those teams could be useful. We'd still most likely default to exhaustiveness, and we'll want to clearly warn/document the trade-offs of turning the dial off.

One thing to note, @larromba, that came up on Twitter is that you can totally test with a ViewStore today if you want to ignore certain effects or state changes. The biggest issue with that is those tests will be written in a different style.

[larromba]

Sounds good @stephencelis - thanks 🙏