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

# Finding the issue

The first step of any stateful failure is to figure out which failing sequence caused the problem. Shrinking does most of the job, but we still have to extract meaning out of it. We have something similar to the following:


This creates a sequence of events and state transitions as follows:


At least, that’s the expectation from the history we have. But for the last error call, we'd expected to see `{error, {circuit_breaker, _}}` since we’re in the `tripped` state. Instead, the call returned `{error, ignore2}`, which contradicts our expectations of the `tripped` state. This means our model’s state machine and the real system are out of sync. 

The underlying cause for this can be found in circuit breaker’s source code. After a code dive, we found out that the actual circuit breaker doesn’t just look for any `N` failures in a period of time, but instead decreases the counter by `1` on every successful call, first on errors, and then on timeouts. It will also only do this after some failures have already been registered. If, for example, every failing call is immediately followed by a successful one, as long as the breaker tolerates more than one failure, it will never trip. So, for it to trip we’ll need a higher ratio of failures than successful calls over time to trip it. This is a small but very important detail when defining failure thresholds.



Take a look at what causes the tests to fail and how to resolve the issue.

Adjusting the Model: Fixing the Issue

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

Adjusting the Model: Fixing the Issue

Finding the issue