The Program Structure

Design strategy

The most important thing we can do to make our testing experience easier is to design an inherently testable system. To do this well, thinking about the observable effects we want to test against is crucial. In object-oriented code, the traditional approach asks us to limit ourselves to specific objects and to observe their behavior and side effects. Mocking and dependency injection help keep the test scope from growing too large.

In the case of Erlang, these practices can and will make sense when testing specific actors, although this may bring us closer to integration testing. Since we are practicing functional programming, side effects can be grouped at one end of the system, and we can keep the rest of the code as pure as possible. Let’s see how we could classify the different actions in our program:

Side-Effect	Functional
Reading a flat file	Converting CSV data to employee records
Finding today’s date	Searching for employees based on a date
Sending an email	Formatting an email as a string

Everything in the left Side Effect column will go to integration testing. Everything in the right Functional column will go into the unit tests. In fact, if we use this classification to design the entire system, we’ll be able to test fairly straightforward code, as shown in the figure below: