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

# What are symbolic calls?

Some of the data structures or states that we need to generate for tests can be opaque and difficult to decipher. Think of debugging a binary protocol by looking at the individual bytes once the whole thing is encoded, or creating a process and sending it a bunch of messages to prime its state. The output of a failing property will be a lot of hard-to-read bits and bytes, or a term like `<0.213.0>`, which is not very helpful regardless of how much shrinking we may apply to them. The solution to this problem is a special category of generators built from symbolic calls.

A symbolic call is just a special notation for function calls so that they can be represented as data in generators. Rather than executing the operation straight away, the calls are built up as a data structure. Once the generator materializes, they are executed at once. The notation for them is `{call, Module, Function, ArgumentList}`.This is the format supported by PropEr. Another format, `{$call, Module, Function, ArgumentList}`, named automated symbolic call, is similar, but a bit easier in practice:

|**Function Call**|**Symbolic Call**|**Automated Symbolic Call (PropEr only)**|
|-|-|-|
|`sets:new()`|`{call, sets, new, []}`|`{'$call', sets, new, []}`|
|`queue:join(Q1, Q2)`|`{call, queue, join, [Q1, Q2]}`|`{'$call', queue, join, [Q1, Q2]}`|
|`lists:sort([1,2,3])`|`{call, lists, sort, [[1,2,3]]}`|`{'$call', lists, sort, [[1,2,3]]}`|
|`local(Arg)` (if exported)|`{call, ?MODULE, local, [Arg]}`|`{'$call', ?MODULE, local, [Arg]}`|

Using either format of symbolic calls can make things simpler when looking at shrunken results. Let’s try an example using the `dict` data structure, which can be opaque if we don’t know how it’s implemented. 

# Example
Take a look at an example to learn the difference between symbolic calls and automated symbolic calls. 



# What are symbolic calls?

Some of the data structures or states that we need to generate for tests can be opaque and difficult to decipher. Think of debugging a binary protocol by looking at the individual bytes once the whole thing is encoded, or creating a process and sending it a bunch of messages to prime its state. The output of a failing property will be a lot of hard-to-read bits and bytes, or a term like `<0.213.0>`, which is not very helpful regardless of how much shrinking we may apply to them. The solution to this problem is a special category of generators built from symbolic calls.

A symbolic call is just a special notation for function calls so that they can be represented as data in generators. Rather than executing the operation straight away, the calls are built up as a data structure. Once the generator materializes, they are executed at once. The notation for them is `{call, Module, Function, ArgumentList}`.This is the format supported by PropEr. Another format, `{＄call, Module, Function, ArgumentList}`, named automated symbolic call, is similar, but a bit easier in practice:

|**Function Call**|**Symbolic Call**|**Automated Symbolic Call (PropEr only)**|
|-|-|-|
|`sets:new()`|`{call, sets, new, []}`|`{'＄call', sets, new, []}`|
|`queue:join(Q1, Q2)`|`{call, queue, join, [Q1, Q2]}`|`{'＄call', queue, join, [Q1, Q2]}`|
|`lists:sort([1,2,3])`|`{call, lists, sort, [[1,2,3]]}`|`{'＄call', lists, sort, [[1,2,3]]}`|
|`local(Arg)` (if exported)|`{call, ?MODULE, local, [Arg]}`|`{'＄call', ?MODULE, local, [Arg]}`|

Using either format of symbolic calls can make things simpler when looking at shrunken results. Let’s try an example using the `dict` data structure, which can be opaque if we don’t know how it’s implemented. 

# Example
Take a look at an example to learn the difference between symbolic calls and automated symbolic calls. 



Learn about symbolic calls and how they make debugging a property failure easier.

Symbolic Calls

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

Symbolic Calls

What are symbolic calls?