Why Property-based Testing?
Take a look at property-based testing and its advantages over standard testing techniques.
Testing
Testing can be a boring task, but it’s a necessity we can’t avoid. Tests are critical to creating a reliable program, especially one that changes over time. They can also prove useful in helping design programs. They are ideal for helping us write tests as users as well as implementers. But mostly, tests are repetitive and sometimes burdensome work.
Take a look at this example test that checks that an Erlang function can take a list of presorted lists and always return them merged as one single sorted list:
merge_test() ->[] = merge([]),[] = merge([[]]),[] = merge([[],[]]),[] = merge([[],[],[]]),[1] = merge([[1]]),[1,1,2,2] = merge([[1,2],[1,2]]),[1] = merge([[1],[],[]]),[1] = merge([[],[1],[]]),[1] = merge([[],[],[1]]),[1,2] = merge([[1],[2],[]]),[1,2] = merge([[1],[],[2]]),[1,2] = merge([[],[1],[2]]),[1,2,3,4,5,6] = merge([[1,2],[],[5,6],[],[3,4],[]]),[1,2,3,4] = merge([[4],[3],[2],[1]]),[1,2,3,4,5] = merge([[1],[2],[3],[4],[5]]),[1,2,3,4,5,6] = merge([[1],[2],[3],[4],[5],[6]]), [1,2,3,4,5,6,7,8,9] = merge([[1],[2],[3],[4],[5],[6],[7],[8],[9]]), Seq = seq(1,100),true = Seq == merge(map(fun(E) -> [E] end, Seq)),ok.
This is slightly modified code taken from the Erlang/OTP test suites for the lists module, one of the most central libraries in the entire language. Here, the developer is trying to think of all the possible ways the code can be used and make sure that the result is predictable. We can probably think of another ten or thirty lines that could be added, that are significant and explore the same code in somewhat different ways. Nevertheless, it’s perfectly reasonable, usable, readable, and effective test code. The problem is that ...