We have now written some truly powerful tests. Not only are we testing how the state of the application evolves as the user does various things in the UI, but we are also performing end-to-end testing on effects by asserting that the right effect executes and the right action is returned.

We do want to mention that the way we have constructed our environments is not 100% ideal right now. It got the job done for this application, but we will run into problems once we want to share a dependency amongst many independent modules, like say our PrimeModal module wanted access to the FileClient. We’d have no choice but to create a new FileClient instance for that module, which would mean the app has two FileClients floating around. Fortunately, it’s very simple to fix this, and we will be doing that in a future episode really soon.

Another thing that isn’t so great about our tests is that they’re quite unwieldy. Some of the last tests we wrote are over 60 lines! So if we wrote just 10 tests this file would already be over 600 lines.

There is a lot of ceremony in our tests right now. We must:

• create expectations

• run the effects

• wait for expectations

• fulfill expectations

• capture the next action

• assert what action we got and feed it back into the reducer.

That’s pretty intense to have to repeat for every effect we test, and as we mentioned it doesn’t even catch the full story of effects since some extra ones could have slipped in.

Maybe we can focus on the bare essentials: the shape of what we need to do in order to assert expectations against our architecture. It seems to boil down to providing some initial state, providing the reducer we want to test, and then feeding a series of actions and expections along the way, ideally in a declarative fashion with little boilerplate!