Can't read the pdf right now but I'm a big fan of property based testing.
One thing I find that people struggle with is coming up with "good properties" to test with.
That's the wrong way to think about it. The properties you want to test are the function's contract. Checking that contract is the goal.
You can be as specific with the contract as you want. The more specific the more bugs you'll find.
Property-based tests are just one way to check the contract, as are hand-written unit tests. You could use a static analyzer or a model checker as well, they're all different approaches to do the same thing.
EDIT: by contract I mean the guarantees the function imposes on its output. A contract for a sorting function could be as simple as the length of the output being the same as the input. That's one property. Another is that every element in the output is also in the input. You can go all the way and say that for every element at index i, the element at index i+1 (if any) is larger.
But you don't need a perfect contract to start with nor to end with. You can add more guarantees/properties as you wish. The more specific, the better (but also slower) the tests.
One thing I find that people struggle with is coming up with "good properties" to test with.
That's the wrong way to think about it. The properties you want to test are the function's contract. Checking that contract is the goal.
You can be as specific with the contract as you want. The more specific the more bugs you'll find.
Property-based tests are just one way to check the contract, as are hand-written unit tests. You could use a static analyzer or a model checker as well, they're all different approaches to do the same thing.
EDIT: by contract I mean the guarantees the function imposes on its output. A contract for a sorting function could be as simple as the length of the output being the same as the input. That's one property. Another is that every element in the output is also in the input. You can go all the way and say that for every element at index i, the element at index i+1 (if any) is larger.
But you don't need a perfect contract to start with nor to end with. You can add more guarantees/properties as you wish. The more specific, the better (but also slower) the tests.