Martin Janiczek

Senior Frontend Engineer @ Vendr

I love to start things and little one-off experiments. Drive for teaching and unblocking others (most often seen on the Elm Slack). Interests include: compilers, programming language design, property based testing. Maintainer of the elm-test library. Every December I wake up early for Advent of Code, don't know why.

*: not all the things.


The audience should be able to take away:
- understanding of property-based testing and what it's good for
- a better intuition for properties they can test in their own code
- a high-level idea of how a property-based testing library works under the hood and how to implement it


Functional programmers, people who like TDD, PBT, math properties, correctness. People who write standard libraries


I'm a big proponent of property-based testing (as in, QuickCheck or Hypothesis), be it in Elm, Haskell, Scala or JavaScript - it's great at finding tricky edge cases, refining your understanding of your system and giving you confidence it works for more cases than just your happy path unit tests.

Imagine my horror when I saw that SerenityOS, my favorite "watch and admire it from distance" open source project didn't have any support for property-based testing! There were three options: don't test at all, test with unit tests, or fuzz the binary as a black box.

I set out to write a property-based testing framework for SerenityOS, complete with automatic shrinking and all, and to use it to write property tests for apps and libraries all across SerenityOS.

In this talk I want to share that journey, the surprising complications and how I overcame them, the tests I've written and categories they fall into, and the bugs I've found.