Gain insights into property-based testing with PropEr in Elixir. Learn foundational principles, custom data generators, and advanced concepts for effective real-world application testing.

Property Based Testing with PropEr in Elixr_468 x 60 copy.png

propert-based-testing.tar.gz

Erlang

Elixer

Erlang-Chap2

Elixir-Chap2

Erlang-Shell

erlang-user

elixir-user

elixir-shell

elrang-eunit

erlang-chap5-employee

elixir-cover_test

erlang-cover_test

erlang-chap10-databaseinit

erlang-chap10-user

elixir-chap10-user

erlang-chap10-shell

elixir-chap10-shell

erlang-chap10-dbsetup

elixir-chap10-dbSetup

erlang-chap5-templating

erlang-chap5-last

elixir-chap5-last

erlang-chap10-default

elixir-chap10-default

elixir-chap10-default-copy

Erlang-Chap2-copy

Elixir-Chap2-copy

Erlang-Shell-copy

elixir-shell-copy

erlang-default-force

elixir-default-force

erlang-test-shell

elxir-test-shell

Property-based testing relies on specifying some property of code, unlike unit tests, which specify the expected output in response to some inputs. In this course, we'll cover the concepts we need to feel confident about using even the most advanced features of PropEr with Elixir.

We'll start with the basic and foundational principles of property-based testing, see what the framework offers us to get started, make our way through thinking in properties, write our own custom data generators, and then learn more advanced concepts. We'll also see how you can use property-based testing in a realistic project.

By the time we finish this course, we should feel comfortable testing real-world applications using properties.

Property-Based Testing with PropEr in Elixir

## The property

Let's start by looking at the property. 

property "FSM property for circuit breakers", [:verbose] do
  Application.stop(:circuit_breaker) # we take over that
  forall cmds <- commands(__MODULE__) do
    {:ok, pid} = :circuit_breaker.start_link()
    {history, state, result} = run_commands(__MODULE__, cmds)
    GenServer.stop(pid, :normal, 5000) #(1)

    (result == :ok)
    |> aggregate(
      :proper_statem.zip(state_names(history), command_names(cmds))
    )
    |> when_fail(
      IO.puts("""
      History: #{inspect(history)}
      State: #{inspect(state)}
      Result: #{inspect(result)}
      """)
    )
  end
end

There will be four generators:
* `ok/1`
* `tripped/1` 
* `blocked/1`
* `unregistered/1`
  * This fourth generator is added because manual calls aren’t available until the circuit breaker’s service id is registered, which occurs automatically on the first use. This peculiarity will be encoded into the state machine itself.

Here we are starting the circuit breaker process by hand, which is paired with a call to `gen_server:stop/3` at **line 6**.  The circuit breaker module doesn’t expose a callback to terminate the breaker, usually preferring to let a supervision tree do that work. However, the `gen_server` behavior exposes functions that let us bypass that by ordering the process to stop itself. Aside from this, the property is rather straightforward. 

## The model 

The model itself is where most of the complexity might live. The first set of call backs we’ll want to tackle are those that are initializing the state and data for the state machine. We’ll want to track the number of failures seen for each type, and the total number of failures we should expect before the breaker trips. Let's take a look at how this is done:

```elixir
## Initial state for the state machine
def initial_state(), do: :unregistered

## Initial model at the start. Should be deterministic
def initial_state_data() do
  %{limit: 3, errors: 0, timeouts: 0} 
end
```

We start by defining `#data{}` record. The two callbacks then specify that we’ll start in the unregistered state, with the data set to its default value. As mentioned earlier, the unregistered state lets us represent the fact that manual calls need the service to be registered to be available. Overall, our circuit breaker state machine should be able to transition as shown in the diagram below:

# The property

Let's start by looking at the property. 

There will be four generators:
* `ok/1`
* `tripped/1` 
* `blocked/1`
* `unregistered/1`
  * This fourth generator is added because manual calls aren’t available until the circuit breaker’s service id is registered, which occurs automatically on the first use. This peculiarity will be encoded into the state machine itself.

Here we are starting the circuit breaker process by hand, which is paired with a call to `gen_server:stop/3` at **line 6**.  The circuit breaker module doesn’t expose a callback to terminate the breaker, usually preferring to let a supervision tree do that work. However, the `gen_server` behavior exposes functions that let us bypass that by ordering the process to stop itself. Aside from this, the property is rather straightforward. 

# The model 

The model itself is where most of the complexity might live. The first set of call backs we’ll want to tackle are those that are initializing the state and data for the state machine. We’ll want to track the number of failures seen for each type, and the total number of failures we should expect before the breaker trips. Let's take a look at how this is done:

```elixir
## Initial state for the state machine
def initial_state(), do: :unregistered

## Initial model at the start. Should be deterministic
def initial_state_data() do
  %{limit: 3, errors: 0, timeouts: 0} 
end
```

We start by defining `#data{}` record. The two callbacks then specify that we’ll start in the unregistered state, with the data set to its default value. As mentioned earlier, the unregistered state lets us represent the fact that manual calls need the service to be registered to be available. Overall, our circuit breaker state machine should be able to transition as shown in the diagram below:

Start off with the test module and take a look at the property and the generators of the FSM tests. 

Modeling the Circuit Breaker: The Property

Start off with the test module and take a look at the property and the generators of the FSM tests.

Foundations of Property-Based Testing

Writing Properties

Thinking in Properties

Custom Generators

Responsible Testing

Properties-Driven Development

Shrinking

Stateful Properties

Case Study: Bookstore

State Machine Properties

Conclusion

Modeling the Circuit Breaker: The Property

The property