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

As with the last chapter, the parallel version of our system can be adapted by just declaring a new property and reusing the same model, to see if any glaring concurrency issues can be found.

Let's take a look at the property and then see it in action in the code widgets below.

# Code

The `prop_parallel` property in the following code has been highlighted for us. 

import React from 'react';
import { shallow, configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

import HelloWorld from './app';

var TestResult = function() {
    this.succeeded = false;
    this.reason = "";
    this.input = "";
    this.expected_output = "";
    this.actual_output = "";
}

export const executeTests = function() {

  var results = [];

  result = new TestResult();
  result.input = 'HelloWorld Component';
  result.expected_output = "span containing text 'Hello World'"

  let wrapper = shallow(<HelloWorld />);

  // Call your Challenge function here.

  let type = wrapper.type();
  let testSuccessful = true;
  let failureReason;

  if (type !== 'span') {
    testSuccessful = false;
    failureReason = "You need to render exactly one span HTML element";
  } else if (wrapper.props().children != "Hello World") {
     testSuccessful = false;
     failureReason = "You have rendered wrong message in your span element";
  }

  result.actual_output = wrapper.html();

  if (testSuccessful) {
    result.succeeded = true;
    result.reason = "Succeeded"
  } else {
    result.succeeded = false;
    result.reason = failureReason;
  }

  results.push(result);

  return results;
}


React

Dart

GoJS React

Typescript React

Vue.js

Once again, few changes are required aside from the names of the generator function and the function to run commands. We can run it and see it pass.

As we also saw in the last chapter, the PropEr parallel tests are not necessarily great at finding concurrency issues, so we shouldn’t take this as proof of success. We can try to add `erlang:yield()` calls in multiple areas, but it won’t necessarily uncover much. Careful analysis can always help clarify things.

It turns out that, by default, any PostgreSQL query runs in an implicit transaction even if we don’t specify one. Those transactions run in `read committed` isolation levels and are all simple `SELECT` and `UPDATE` queries with no external data and no need for reads from other queries. This means the operations are safe for concurrency. The one case that could look unusual is the last one we changed, where we check whether a book exists before borrowing it. Since the two operations aren’t in a transaction, there could be a risk of bad results where the wrong kind of error is returned. Still, no operation would succeed where it shouldn’t.

In any case, these tests will help in case the implementation changes, or when some unsafe query usage or pooling takes place, rather than one connection per request like the project currently uses.

With all this, we now have nearly complete integration tests for the application’s interactions with the database. Connectivity failures are still left untouched, but those may be more interesting to cover in another property. It’s better to take care of this later than make this test more complex than it needs to be. 


With this, we’ve seen most of what there is to see with stateful properties. The one exception is a specialization for systems that represent finite state machines, which we’ll get to discover next.

Take a look at the parallel testing of the application. 

Parallel Tests

Take a look at the parallel testing of the application.

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

Parallel Tests