Chapter 10. Testing reactive code

In this chapter

Testing fundamentals
Writing tests for reactive applications
Using tools to deal with asynchronous code
Knowing which code to test and which not to test

Reactive architectures and testing

Like it or not, testing at least critical parts of your application is usually a good idea. Reactive applications can seem tricky to test, but the modularization they promote shows the opposite, if you write your code according to these guidelines we’ve been discussing:

Make modules that have as few dependencies as possible.
Prefer pure functions that can be composed for more complex functionality.

Testing granularity

In general, we tend to divide tests into unit testing and acceptance testing. These two test types are focused on different parts of the application and have different goals, as shown in the following lists.

Unit testing	Acceptance testing
Fully tests small fragments of code Doesn’t use framework classes (Android classes) Ideally covers all possible execution paths (providing code coverage) Is fine-grained Usually targets pure functions, small classes	Tests the way that parts of code work together Can use classes from the framework Includes end-to-end testing in the extreme form, testing the full system Doesn’t try to cover all cases Usually targets long chains, large classes

Test granularity

The pyramid of dependencies

Chapter 10. Testing reactive code

In this chapter

Reactive architectures and testing

Testing granularity

Test granularity

The pyramid of dependencies

Unit-testing basics

Testing reactive chains

TestObservable class

Synchronous or asynchronous

Coffee break

Writing tests for view models

Choosing what to test

Testing the GameViewModel initial state

Testing partial observable chains

Testing Connect Four drop logic

Summary