Property-Based Testing in a Project

What we need now is a framework. As opposed to many testing practices that require a tiny bit of scaffolding and a lot of care, property-based testing is a practice that requires heavy tool assistance. Without a framework, we have no way to generate data, and all we’re left with are encoded rules that don’t get validated. If we use a framework that doesn’t generate great data or doesn’t let us express the ideas we need, it will be very difficult to generate tests of the same quality that we could use a functional framework.

As the course title implies, we will use PropEr. It can be used by both Erlang and Elixir projects and integrate with the usual build tools used in both languages. There are other frameworks available, namely QuickCheck framework by Quviq and Triq. These two frameworks and PropEr are similar enough that if our team is using any of them, we’ll be able to follow along with the text without a problem. This remains true if you’re using Elixir. You might have heard about StreamData, a property-based testing framework exclusive to Elixir. The concepts should not be hard to carry over from framework to framework in any case.

PropEr is usable on its own through either manual calls or command line utils. This is fine for some isolated tests and quick demos, but it’s usually nicer to be able to get the framework to fit our everyday development workflow instead.

rebar3: Erlang build tool

For Erlang, we’ll use rebar3 as our build tool.

If you’ve used the Common Test or EUnit frameworks before, you may know that you can use rebar3 ct or rebar3 eunit to run the tests for our project. To keep things simple, we’ll use a PropEr plugin that will let us call rebar3 proper and get similar results. That way, everyone feels at home despite using brand-new tools.

Suppose you’re one of the folks who enjoy putting unit tests along with the source code. In that case, we need to know that PropEr requires a different approach, more in line with Common Test’s vision: tests are in a separate directory and don’t become part of the artifacts that could ever end up in production.

Fear Not the GPLv3 License:
PropEr is licensed under the GPLv3. People are often worried about attaching and shipping GPL-licensed code with their projects. Placing the tests and dependencies related to PropEr in their directory means that they are only used as development tools in a testing context and never in production.
As such, whenever we build a release with code to ship and deploy, none of the test code nor PropEr itself will be bundled or linked to our program. This tends to put most corporate lawyers at ease without preventing the authors from getting contributions back if the tool is modified or used at the center of a commercial product.

Setting up a new project

To make a new Erlang project, we can run the command:

rebar3 new lib newProj

Try running the command in the terminal below to see how it works.

Adding the PropEr dependency

That’s a regular library project named newProj. The PropEr plugin and dependency must be added to the configuration of each project we want to use them with. We do this by editing the rebar.config file to contain the dependency. Take a look at it in the rebar.config file open in the code widget below.

Running the project

The command we use to test property-based Erlang projects in a terminal is:

rebar3 proper

Let’s call it in the code widget below and see its output.

Note: To execute the code after changing it, please click “Run,” which will save your code, and then run rebar3 proper in the terminal.

Remember: Don’t be worried if the output shows 0/0 properties passed. We have not made any properties yet.

---

We’ve learned how to set up Erlang projects with PropEr to use property-based testing. We can now move on to running properties.