PickCheck : Property-based testing in Pascal

[I originally wrote this a month ago. Putting updates below.]

Git repo: https;//gitlab.com/bolsen80/pickcheck.git

I have a hobby project to make an exchange order book and then maybe wrap a bigger workflow around it. So, I started to write a function: it is a simple function that takes two orders and tries to fill both of them:

Here is a basic rule for a simple ordering type:

1. Each have to serve opposite ends: a buy order and a sell order.
2. A sell order has to have a quantity to sell,
3. A buy order has to have a quantity unfilled.
4. At the end, the sell order tries to get rid of much of its quantity that the buy order requests. It can be less than the buy order, but we just want to maximalize the quantity of product to deliver to the buy side.
5. At the end, there should be no extra product being created; i.e. the number of product between them is passed exactly.

Unsurprisingly, this is a type of motivation for property-based testing listed in the Hypothesis tutorial, which is a Python library for this same purpose. https://hypothesis.readthedocs.io/en/latest/tutorial/introduction.html:

"Other examples of properties include:

An optimized implementation is equivalent to a slower, but clearly correct, implementation.

A sequence of transactions in a financial system always “balances”; money never gets lost.

The derivative of a polynomial of order n has order n - 1.

A type-checker, linter, formatter, or compiler does not crash when called on syntactically valid code."

"

With the increase in the type of rules, there would be a potential combinatorial explosion of test cases. The last case the author mentions is a particular problem that is potent, because anything processing some language at whatever level has to deal with an infinite number of wrong inputs. In reality, it's getting good at saying "NO!" to input.

When I started to write this, I thought of test cases, but then felt bad, because I hate thinking of verifiable test cases. But the above act like post-conditions to the function, using design-by-contract language.

I knew about QuickCheck for a long time, but I wanted to see if this would solve my woe. QuickCheck started life in Haskell, with this paper: https://dl.acm.org/doi/10.1145/351240.351266.

Since I am writing this in Pascal, there wasn't anything of the sort. So this is a big random distraction. :)

So the value proposition is this: I want something to produce me lots of random Order objects and write property tests to verify these scenarios. As I create new order types, the original properties can be used as regressions.

The difference with unit testing is that I can generate lots random test cases. The tool tells me when a property is "falsifiable", leading me to find the reason why the system reached this case.

This is really good for referentially-transparent functions or probably systems exhibiting this property. This is the first target, but other QuickCheck libraries can offer inspiration as to how to handle testing when there are side-effects.

Updates: 2025-10-22

Hacking on things is very much an on-and-off thing. So, much hasn't happened since I wrote this on Sept. 8. However, there is a few things:

1. The tool has been tightened up via the API, but there is some work to do when it comes to the specifiers.
2. I switched to Delphi syntax, but I learned why ObjFPC uses specialize and generic a lot, from a thread I opened on the Lazarus forum: https://forum.lazarus.freepascal.org/index.php/topic,72265.0.html. The switch to Delphi syntax is a bit related to the fact that Generics.Collections is written in that. Also, I just downloaded Delphi (not a Windows user outside of work) just to grab the compiler and test this out.