3 ms·
I've tried to use property based testing but always found it falls between two stools. If I understand a property well enough to write a strict test of it, I ca
by lmm 2y ago
I've tried to use property based testing but always found it falls between two stools. If I understand a property well enough to write a strict test of it, I can generally push it into the type system and make it true by construction. And if I just want a "smoke test" then a single arbitrary input is easier.
- eru 2y agoWhat kinds of properties you have in mind? For example, a lot of times I might have two implementations, a naive one that's slow and simple, and an optimized one. I can compare the output of both against each other on arbitrary input. That's a simple property that easy to understand, but hard to put in the type system in general. Similarly, I often have properties that eg the order that input is presented in shouldn't matter, or sometimes you have ways to partition your data 'max(maximum over A, maximum over B)) = maximum(A union B)'. How do you encode that in the type system? Or you have something like 'for any A and B: (find some optimal solution over A) is worse than (find some optimal solution over (A union B))'. Or you have idempotency like 'f(f(A)) = f(A)'. These are all easy to understand properties, but not trivial to describe in most type systems.
- munchler 2y agoClearly it's better to enforce constraints at compile-time, if possible. However, there are many kinds of constraints that mainstream type checkers just can't handle. (Dependent types would help a lot, but still seem limited to niches, such as theorem provers.)