Unlock This Episode
Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.
This test now passes, and proves that if an API request is in flight, then tapping the “Cancel” button will definitely prevent those requests from completing and feeding their data back into the system.
And so that’s all there is two immediate schedulers, our 3rd “better test” dependencies in this series. Over the past 3 episodes we have shown that it is quite fruitful to explore ways to improve the ways we construct dependencies for our tests.
- First we showed there’s a lot of power in being exhaustive with dependencies. It allows us to instantly see what a part of our feature is using a dependency we don’t expect, and it allows us to layer on new functionality and be instantly notified of what tests need to be updated.
- However, the ergonomics of that weren’t great, and so we explored a way to improve the situation by failing the test suite when a dependency is incorrect accessed rather than crashing the suite. This came with some new complications, but ultimately we were able to workaround them.
- And then finally we showed that just because we want to control asynchrony in our tests it doesn’t necessarily mean we need to use a
TestScheduler, whose primary purpose is to control the flow of time in tests. Sometimes it’s perfectly fine to squash all of time into a single point, and that makes are tests even shorter and more concise.
And so it’s usually around this time the we ask the all important question “what’s the point?” This is our moment to bring things down to earth and show real world applications of the things we talk about.
Everything we’ve done so far has been quite real world, but we can still go deeper. We are going to demonstrate two important things:
- Even though our focus of this episode has been on testing, there is an invariable certainty of programming that when you do a little bit of upfront work to make your code more testable or more easily tested you will naturally have other benefits that have nothing to do with tests. And so our focus on building better dependencies for tests actually have some really surprising and amazing applications to other parts of our development of applications.
So let’s get started!
A word game by us, written in the Composable Architecture.
Open source game built in SwiftUI and the Composable Architecture.
There’s a lot of great material in the community covering almost every aspect of the Combine framework, but sadly Combine’s
Schedulerprotocol hasn’t gotten much attention. It’s a pretty mysterious protocol, and Apple does not provide much documentation about it, but it is incredibly powerful and can allow one to test how time flows through complex publishers.
We develop the idea of dependencies from the ground up in this collection of episodes:
Let’s take a moment to properly define what a dependency is and understand why they add so much complexity to our code. We will begin building a moderately complex application with three dependencies, and see how it complicates development, and what we can do about it.
We made dependencies a first class concern of the Composable Architecture by baking the notion of dependencies directly into the definition of its atomic unit: the reducer.
The Composable Architecture is a library for building applications in a consistent and understandable way, with composition, testing and ergonomics in mind.