PonyCheck is Pony’s property based testing framework. It is designed to work seamlessly with PonyTest, Pony’s unit testing framework. How is property based testing different than unit testing? Why does Pony include both?
In traditional unit testing, it is the duty and burden of the developer to provide and craft meaningful input examples for the unit under test (be it a class, a function or whatever) and check if some output conditions hold. This is a tedious and error-prone activity.
Property based testing leaves generation of test input samples to the testing engine which generates random examples taken from a description how to do so, so called Generators. The developer needs to define a Generator and describe the condition that should hold for each and every input sample.
Property based testing first came up as QuickCheck in Haskell. It has the nice property of automatically inferring Generators from the type of the property parameter, the test input sample.
PonyCheck is heavily inspired by QuickCheck and other great property based testing libraries, namely:
Writing property based tests in PonyCheck is done by implementing the trait Property1. A Property1 needs to define a type parameter for the type of the input sample, a Generator and a property function. Here is a minimal example:
A Property1 needs a name for identification in test output. We created a Generator by using one of the many convenience factory methods and combinators defined in the Generators primitive and we used PropertyHelper to assert on a condition that should hold for all samples
Below are two classic list reverse properties from the QuickCheck paper adapted to Pony arrays:
PonyCheck properties need to be executed. The test runner for PonyCheck is PonyTest. To integrate Property1 into PonyTest, Property1 needs to be wrapped inside a Property1UnitTest and passed to the PonyTest apply method as a regular PonyTest UnitTest: