Test logics by running them through middleware in mock store

[outoftime]

Instead of exercising logics by calling the process() method directly, creates a makeTestLogic test helper that sets up a mock store with the redux-logic middleware configured with only the logic under test.

This change was initially motivated by an observation that several of our logic tests were relying on the implementation detail that our process() methods tend to be async methods that settle when the logic is done; however, in those cases, what actually matters is the done() callback being called.

After a first cut that created a test helper that replicated the way redux-logic handles different implementations of the process() method, I still didn’t like how much manual testing of Observables and such we had to do for the more advanced logics.

So, instead, test logics by running them through redux-logic. The test helper abstracts creating the middleware and mock store, so actual tests are still just concerned with the behavior of the logic. The helper returns a promise that resolves when the logic completes, by hooking into the global monitor$ observable in redux-logic. Tests can optionally pass an afterDispatch function to trigger behaviors that the logic waits for.

It’s reasonable to question whether this approach really qualifies as unit testing—after all, we’re creating an entire Redux store to test behavior here—but I think it still fully qualifies. We’re still testing one particular software component (a logic) in isolation from the rest of our application; the question is just how to test that component most effectively. In the case of redux-logic, the behavior of the logic is the result of a fairly complex interaction between our code and library code; so testing it in the context of the library is the best way to ensure that it’s working the way we want.

As it happens, switching to the helper caught a bug in one of the logic’s implementations, which is fixed here as well.