Gain insights into property-based testing with PropEr in Erlang. Delve into foundational principles, common frameworks, custom data generators, and applying testing in realistic projects for robust code validation.

Property Based Testing with PropEr in Erlang_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, rather than unit tests which specify the expected output in response to some inputs. In this course, you’ll cover the concepts you need to get started, up to the point where you feel confident enough to use the most advanced features of PropEr with Erlang.

You’ll start smoothly with the basic and foundational principles of property-based testing. From there, you will cover some of the common frameworks, how to think in properties, how to write your own custom data generators, and more. You'll also see how you can use Property-Based Testing in a realistic project.

By the time you finish this course, you will be comfortable testing real-world applications using properties.

Property-Based Testing with PropEr in Erlang

# The layout
State machine properties are very similar to regular stateful properties, conceptually speaking. They share the same three major components:

- A model, which represents what the system should do at a high level.
- A generator for commands, which represent the execution flow of the program.
- An actual system, which is validated against our model.

Since FSM properties are really a specialization of stateful properties, the differences are subtle. 

# The model
The model for state machine properties keeps the same spirit as other models. It must be a straightforward version of our system, used to ensure the real system acts according to our expectations. FSM properties are made of three parts:

1. A data structure that represents the expected state of the system.
2. The name of a state representing the name of the modeled finite state machine (either an atom or a tuple).
3. A function that transforms the model’s data based on commands that could be applied to the system, named `next_state_data`. 

The model is similar to stateful properties, but with state names as an extra thing to keep in mind.

> **Note:** When dealing with stateful components in Erlang, we often refer to their “state” as the ensemble of data that is living within the component. In fact, “state” and “data” are often used interchangeably. When dealing with finite state machines, we need to be accurate. “State” refers to the name of the state the FSM is in (a lock is in either locked or unlocked states), and “data” refers to the actual information and records being held by the FSM. For instance, The combination to open the lock is 3-13-37 and may be held in its data.


# The commands

As with stateful properties, FSM properties have command generators. They work a bit differently since they’re based on the state. These command generators contain the following:

1. A list of functions sharing the name of the states, each of which returns a list of symbolic calls with generators defining their arguments, along with the name of the next state to transition to.
2. A series of preconditions defining whether a given symbolic call would make sense to apply according to the current model state and data.
3. An optional callback that defines the probability for a given state transition to happen. If no weight is defined, all transitions are equally likely.

# The validation

When it comes to validating our system against the model, we’ll once again borrow a lot from stateful properties. The mechanism here relies fully on postconditions, with the one distinction that the state names involved in a transition are considered in the system.


With that in mind, we can now look at the execution mode of FSM properties. 

Take a look at the layout of finite-state properties and the details of the parts of the finite-state properties.

Laying Out State Machine Properties

Foundations of Property-Based Testing

Writing Properties

Thinking in Properties

Custom Generators

Responsible Testing

Properties-Driven Development

Shrinking

Targeted Properties

Stateful Properties

Case Study: Bookstore

State Machine Properties

Conclusion

Laying Out State Machine Properties

The layout

The model