Towards QA I: Property Based Testing

This is the first part of a series of posts where we discuss different approaches in the QA process. Each will cover an aspect of the problem; this may be unit testing, regression testing, systems testing, optimisation and so on so fourth. This post will focus on the world of Property Based Testing (PBT).

PBT is a form of unit testing which is focused on defining conditions and behaviours we expect our functions and types to obey. Traditional unit tests may construct a set of inputs and assert results on the output. In contrast, a PBT may construct a myriad of inputs via generators and assert high level properties that should hold for all cases.

For example, a set of traditional unit tests might take a number of lists as input and assert a set of results on the outputs. The key here is that we, as developers, define the input list and output assertions for a specific set of inputs. We must therefore be careful to ensure we don’t miss any critical cases for lists (be it empty lists, singleton lists, or lists of length n). In PBT, we specify generators for random sets of input types (in this case Lists), and post-conditions that all these lists must satisfy. Provided the input set size is randomised effectively and uses a large enough sample size, we alleviate ourselves from the burden of missing input cases and can focus on the the properties that are under scrutiny.

In this post we will cover ScalaCheck, which is a Scala library inspired by Haskell’s QuickCheck library, which enables PBT.

Originally published at www.datareply.co.uk.