Writing unit tests is pretty much established practice and in addition to that, property testing has caught up on popularity. Most functional languages have one, sometimes even many implementations. But "property testing" has a lot of aspects: randomized or exhaustive, minimization and generalization of counter examples, custom generators and filters, to name a few. Very often, property tests don't exploit all the features of the framework. In this talk, I'll give an overview of the state of the art of property testing and show some common use cases, techniques and pitfalls.
Click to focus, then use left and right arrow on your keyboard to navigate (or swipe on mobile).
- flatMap(Oslo), Oslo, Norway, May 2nd, 2016
- Scala Matsuri, Tokyo, Japan, June 29th, 2019
- Munich Scala User Group, Munich, Germany, August 21st, 2019
- Belgian Scala User Group, Leuven, Belgium, October 22nd, 2019
- How can I come up with properties?
- There are a bunch of resources on this. Oskar Wickström has done a case study for a non-trivial program (screencast editor). The code is in Haskell, but the general ideas should apply to other programs written in a (purely) functional style. A recent paper on the topic from John Hughes, pioneer of property testing, How to Specify it! is a readable guide to writing properties. Johannes Link, author of a property testing library in Java, has translated this guide to Java.
- How can I introduce properties in my existing code base?
- In my experience, introducing property testing is easier, the more functional and modular the code is. Writing integration-test-style properties is possible, but much more difficult than unit-test-style. The problem is that managing state in properties is much harder than in single examples. Consequently, the first step towards a solution is plain and simple refactoring. This Devoxx talk by Romeu Moura may give some additional guidance.