Combine Schedulers: Testing Time

Episode #104 • Jun 4, 2020 • Subscriber-Only

Combine is a powerful framework and is the de facto way to power SwiftUI applications, but how does one test reactive code? We will build a view model from scratch that involves asynchrony and time-based effects and explore what it takes to exhaustively test its functionality.

Testing Time
Introduction
00:05
Creating a Combine view model
02:16
Testing a Combine view model
19:43
A problem with scheduling
25:43
Adding a more complex feature
29:45
More scheduling
43:19
More complexity
44:25
Next time: controlling time
49:07

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Introduction

Today we are beginning a new topic, and it’s a really fun one. It has been nearly one year since Apple announced the Combine framework, which put a reactive framework in the hands of every single developer for Apple’s platforms. This was a huge announcement, because prior to this, adopting a reactive framework meant bringing in a library like RxSwift and ReactiveSwift. Some people thought those dependencies were too heavy to justify their utility, and others thought the reactive paradigm was too complicated and not worth the effort.

But now that Apple has handed down this framework, and it’s immediately available anytime you are building for Apple’s platforms, there isn’t as much to worry about as there used to be. Even if you do not want reactive code creeping into every part of your application, you can still make use of a bunch of APIs that have been improved using the reactive primitives. For example, there’s no reason to create a URLSession data task from scratch, which you always have to remember to call .resume() on it otherwise it won’t start. Instead you can use the publisher interface to that functionality, and things become quite simpler. Same goes for NSNotificationCenter, which has a nice publisher interface that is much easier to use than the old API.

So, eventually more and more Combine code will be entering your code base, and we think that’s a good thing. It can really express some really powerful ideas in a small, succinct package. What’s not a good thing is that because Combine is so new it is lacking some crucial features. In particular, asynchronous reactive code is very difficult to test with Combine today. The abstractions are there to make this much nicer, but the actual implementations of those abstractions are still missing.

And we think this is an appropriate topic for us to cover on Point-Free because one of the big benefits to functional programming is testing. Typically functional code is very easy to test because you can just plug some data into a function and assert on what came out the other side. So, we’d hope that Combine code is also super testable, after all it is a functional reactive framework, but that sadly is not totally true right now.

So, we are going to fill that gap in the Combine framework, and along the way it is going to give us an excuse to dive deep into an advanced topic of Combine that hasn’t yet gotten much attention in the community.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in

References

combine-schedulers

Brandon Williams & Stephen Celis • Sunday Jun 14, 2020

An open source library that provides schedulers for making Combine more testable and more versatile.

Downloads