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.

• And then we want to truly bring these ideas into the “real world” by showing how all of these techniques are incredibly important to how we developed our new iOS word game, isowords, which we also open sourced less than 2 weeks ago. There are some really cool things we can show off.

So let’s get started!