PurelyFunctional.tv Newsletter 335: Idea: when can you use property-based testing?
From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
When can you use Property-Based Testing?
I'm working on a course on Property-Based Testing, and I'd like to compare it to example-based testing. My understanding of example-based testing is that people recommend you test before you write code. The reason you test before is because once you have written the code, you are very biased toward the details of the implementation. The one exception to this is that after a bug is found, you can add tests that reproduce the bug.
Property-Based Testing is different. It actually works well even after the implementation. Because it generates tests randomly, it won't be biased toward your implementation.
For the course, I've come up with four times that I think Property-Based Testing works well for.
- Before implementing (like example-based tests)
- After implementing (to increase confidence in the code)
- When a bug is reported (to find a way to reproduce it)
- At design time (to verify a design)
Number 3 with property-based tests is different from with example-based tests is because with property-based tests, the testing engine does a search to find a way to reproduce it. In example-based testing, you, the developer, have to find it, then you manually add it as a test case.
Number 4 is also unique to property-based tests. If you're designing a new login system, there are certain invariants you want to ensure, like "no one can set an insecure password". Yet there are many endpoints the operate on the user's account records. Is there some sequence of operations that can lead to a user setting an insecure password? Property-based testing can search for one for you in a simple model, before you've even implemented the system. You can then use the model (called an "oracle") to verify the correctness of the actual implementation.
My question to you is: are there any more times when you can use property-based testing? Have I covered everything? I'd love to hear your thoughts and questions.
Just finished reading 📖
If you're new to functional programming, I wouldn't recommend this one. It talks much more about how to build the abstractions and how to use them than about why. But if you've done FP before, this might be a good book for deepening some concepts. It spends a lot of time showing how functions can be made to compose. Fogus is obviously quite adept with functions.
The title also promises to teach Underscore.js (which has since been supplanted by Lodash), but it only seems to use it as a "missing standard library" instead of teaching how to use it effectively. Much more focus is placed on the humble first-class function. It's a cool exploration, but in my experience, most programmers would be better served with practical techniques for programming with pure functions; skill with map, filter, and reduce; and a bit of algebraic thinking.
Brain skill 😎
Exercise builds neuronal connections, regulates blood sugar, and oxygenates the blood. If your mind is moving slowly, go out for a run or do something strenuous. I don't have any science to back this up, but movement helps me get back to a more grounded mode of thinking.
Currently recording 🎥
Recently, I started a course called Property-Based Testing with test.check. Property-based testing (PBT) is a powerful tool for generating tests instead of writing them. You'll love the way PBT makes you think about your system. And you can buy it now.
I managed to record one lesson before my microphone burned out (I've ordered a new one) and Hurricane Barry moved through the region. The challenges of self-employment. Expect more next week.
- An overview of property-based testing with an example test, in which we test some existing code and see how the process of Property-Based Testing works, shrinkage and all.
I've made the first and fifth lessons free to watch. Go check them out.
Members already have access to the lessons. The Early Access Program is open. If you buy now, you will get the already published material and everything else that comes out at a serious discount. There is already 84 minutes of video, and looking at my plan, this one might be 6-7 hours. But that's just an estimate. It could be more or less. The uncertainty about it is why there's such a discount for the Early Access Program.
Clojure Challenge 🤔
Last week's challenge
The puzzle in Issue 334 was to write an implementation of merge sort.
You can check the submissions out here.
I went the easy route and wrote a straightforward, lazy implementation with no bonuses. I tried a reducers solution but it was not faster.
This week's challenge
It's often useful to know the quartiles of a dataset. The quartiles define the lowest quarter, lowest half, and lowest three quarters data points. Those are typically called q1, q2, and q3. I also like to include q0 and q4, which are the min and max.
q2 is just the median of the dataset. q1 is the median of the lower half of the dataset. And q3 is the median of the upper half of the dataset.
Write a function which calculates the quartiles of a sequence of numbers. You will need to be able to calculate the median (which you can look up easily).
As usual, please send me your answers. I'll share them all in next week's issue. If you send me one, but you don't want me to share it publicly, please let me know.
PS ✍️ Book status
As you may know, I'm writing a book called Taming Complex Software, which is an introduction to functional programming. It has been a long journey and lots of work, but I've turned in the first three chapters for Manning's Early Access Program. The gears are turning inside Manning's publishing machine. Very soon, you will read here and elsewhere that those chapters are available for you to purchase. Stay tuned for more information.