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

## Finite state machines

**Finite state machines (FSM)** are, informally speaking, an abstraction describing specific stateful programs. The program can be in only one of the multiple known states at any given time and transitions from one state to another based on specific inputs or events. For instance, a traffic light can only be red, yellow, or green at any one time and might change from one color to another based on an automated timer or a trigger like a person hitting the cross-street button. Within each state, the program may behave differently.

## Why use state machine properties

Let’s imagine a program that takes special measures depending on whether network connectivity is good, bad, or entirely unavailable. These measures could include forbidding certain actions or enabling new features. Testing this program with stateful properties while keeping them deterministic would create an explosion of possible cases. If there are six possible events and three possible states, we quickly get at least eighteen possible combinations of calls versus states. We would have to do quite a bit of filtering in preconditions to hope to cover all kinds of transitions. 

To help with this, PropEr provides finite state machine properties, which allow us to specifically model state machines. State names and transitions are made into first-class citizens, which allows us to adequately explore their expected transitions in a less cumbersome manner than would be required with regular stateful properties or example tests.


Finite-state properties are specifically helpful when users interact with the system while perceiving multiple states rather an internal state machine. To put it another way, state machine properties are for when the model itself is a state machine, not the system. If there are no specific, discernible states for the user, and therefore no specific, discernible states for the model, regular stateful properties are more appropriate.

# Finite state machines

**Finite state machines (FSM)** are, informally speaking, an abstraction describing specific stateful programs. The program can be in only one of the multiple known states at any given time and transitions from one state to another based on specific inputs or events. For instance, a traffic light can only be red, yellow, or green at any one time and might change from one color to another based on an automated timer or a trigger like a person hitting the cross-street button. Within each state, the program may behave differently.

# Why use state machine properties

Let’s imagine a program that takes special measures depending on whether network connectivity is good, bad, or entirely unavailable. These measures could include forbidding certain actions or enabling new features. Testing this program with stateful properties while keeping them deterministic would create an explosion of possible cases. If there are six possible events and three possible states, we quickly get at least eighteen possible combinations of calls versus states. We would have to do quite a bit of filtering in preconditions to hope to cover all kinds of transitions. 

To help with this, PropEr provides finite state machine properties, which allow us to specifically model state machines. State names and transitions are made into first-class citizens, which allows us to adequately explore their expected transitions in a less cumbersome manner than would be required with regular stateful properties or example tests.


Finite-state properties are specifically helpful when users interact with the system while perceiving multiple states rather an internal state machine. To put it another way, state machine properties are for when the model itself is a state machine, not the system. If there are no specific, discernible states for the user, and therefore no specific, discernible states for the model, regular stateful properties are more appropriate.

Get introduced to state machine properties and why there is a need to use them. 

Introduction to State Machine Properties

Get introduced to state machine properties and why there is a need to use them.

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

Introduction to State Machine Properties

Finite state machines