Chapters
Chapters

Chapters

Hide chapters

Combine: Asynchronous Programming with Swift

First Edition · iOS 13 · Swift 5.1 · Xcode 11

Before You Begin

Section 0: 3 chapters
Show chapters Hide chapters

Section I: Introduction to Combine

Section 1: 2 chapters
Show chapters Hide chapters

Section II: Operators

Section 2: 6 chapters
Show chapters Hide chapters

Section III: Combine in Action

Section 3: 6 chapters
Show chapters Hide chapters

Section IV: Advanced Combine

Section 4: 5 chapters
Show chapters Hide chapters

Section V: Building a Complete App

Section 5: 2 chapters
Show chapters Hide chapters

19. Testing
Written by Scott Gardner

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Studies show that there are two reasons why developers skip writing tests:

  1. They write bug-free code.
  2. Are you still reading this?

If you cannot say with a straight face that you always write bug-free code — and presuming you answered yes to number two — this chapter is for you. Thanks for sticking around!

Writing tests is a great way to ensure intended functionality in your app as you are developing new features and especially after the fact, to ensure your latest work did not introduce a regression in some previous code that worked fine.

This chapter will introduce you to writing unit tests against your Combine code, and you’ll have some fun along the way. You’ll write tests against this handy app:

ColorCalc was developed using Combine and SwiftUI. It’s got some issues though. If it only had some good unit tests to help find and fix those issues. Good thing you’re here!

Getting started

Open the starter project for this chapter in the projects/starter folder. This is designed to give you the red, green, blue, and opacity — aka alpha — values for the hex color code you enter in. It will also adjust the background color to match the current hex if possible and give the color’s name if available. If a color cannot be derived from the currently entered hex value, the background will be set to white instead. This is what it’s designed to do. But something is rotten in the state of Denmark — or more like some things.

Fortunately, you’ve got a thorough QA team that takes their time to find and document issues. It’s your job to streamline the development-QA process by not only fixing these issues but also writing some tests to verify correct functionality after the fix.

Run the app and confirm the following issues reported by your QA team:

Issue 1

  • Action: Launch the app.
  • Expected: The name label should display aqua.
  • Actual: The name label displays Optional(ColorCalc.ColorNam….

Issue 2

  • Action: Tap the ← button.
  • Expected: The last character is removed in the hex display.
  • Actual: The last two characters are removed.

Issue 3

  • Action: Tap the ← button.
  • Expected: The background turns white.
  • Actual: The background turns red.

Issue 4

  • Action: Tap the ⊗ button.
  • Expected: The hex value display clears to #.
  • Actual: The hex value display does not change.

Issue 5

  • Action: Enter hex value 006636.
  • Expected: The red-green-blue-opacity display shows 0, 102, 54, 255.
  • Actual: The red-green-blue-opacity display shows 0, 62, 32, 155.

Testing Combine operators

Throughout this chapter, you’ll employ the Given-When-Then pattern to organize your test logic:

Testing collect()

Your first test will be for the collect operator. Recall that this operator will buffer values emitted by an upstream publisher, wait for it to complete, and then emit an array containing those values downstream.

Testing flatMap(maxPublishers:)

As you learned in Chapter 3, “Transforming Operators,” the flatMap operator can be used to flatten multiple upstream publishers into a single publisher, and you can optionally specify the max number of publishers it will receive and flatten.

Testing publish(every:on:in:)

In this next example, the system under test will be a Timer publisher.

Testing shareReplay(capacity:)

This operator provides a commonly-needed capability: To share a publisher’s output with multiple subscribers while also replaying a buffer of the last N values to new subscribers. This operator takes a capacity parameter that specifies the size of the rolling buffer. Once again, refer back to Chapter 18, “Custom Publishers & Handling Backpressure” for additional details about this operator.

Testing production code

At the beginning of the chapter, you observed several issues with the ColorCalc app. It’s now time to do something about it.

Issue 1: Incorrect name displayed

With that setup code in place, you can now write your first test against the view model. Add this code:

Issue 2: Tapping backspace deletes two characters

Still in ColorCalcTests.swift, add this new test:

Issue 3: Incorrect background color

Writing unit tests can very much be a rinse-and-repeat activity. This next test follows the same approach as the previous two. Add this new test to ColorCalcTests:

Testing for bad input

The UI for this app will prevent the user from being able to enter bad data for the hex value.

Challenges

Completing these challenges will help ensure you’ve achieved the learning goals for this chapter.

Challenge 1: Resolve Issue 4: Tapping clear does not clear hex display

Currently, tapping ⊗ has no effect. It’s supposed to clear the hex display to #. Write a test that fails because the hex display is not correctly updated, identify and fix the offending code, and then rerun your test and ensure it passes.

Solution

This challenge’s solution will look almost identical to the test_processBackspaceDeletesLastCharacter() test you wrote earlier. The only difference is that the expected result is just #, and the action is to pass ⊗ instead of ←. Here’s what this test should look like:

Challenge 2: Resolve Issue 5: Incorrect red-green-blue-opacity display for entered hex

Currently, the red-green-blue-opacity (RGBO) display is incorrect after you change the initial hex displayed on app launch to something else. This can be the sort of issue that gets a “could not reproduce” response from development because it “works fine on my device.” Luckily, your QA team provided the explicit instructions that the display is incorrect after entering in a value such as 006636, which should result in the RGBO display being set to 0, 102, 54, 170.

Key points

  • Unit tests help ensure your code works as expected during initial development and that regressions are not introduced down the road.
  • You should organize your code to separate the business logic you will unit test from the presentation logic you will UI test. MVVM is a very suitable pattern for this purpose.
  • It helps to organize your test code using a pattern such as Given-When-Then.
  • You can use expectations to test time-based asynchronous Combine code.
  • It’s important to test both for positive as well as negative conditions.

Where to go from here?

Excellent job! You’ve tackled testing several different Combine operators and brought law and order to a previously untested and unruly codebase.

18. Custom Publishers & Handling Backpressure
20. In Practice: Building a Complete App
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now