TL/DR: The last time we looked at this code, we wrote property tests. The property tests used generators to create input, but the actually testing of the invariants was just regular Elixir code. In this post, we’ll look at rewriting those property tests as standard ExUnit tests, giving us better unit tests.
If you can think in properties, with or without a property testing library, your tests will support refactoring rather than being a barrier to it.
I didn’t figure out what this post is about until I finished it, but here it is: This post is about why and how Unit Testing can be broken in your application. It’s about the difference between good DocTests and good Unit Tests. And ultimately, it’s about thinking in properties. We take a while to get there, and there are some detours, but ultimately, that’s where we’ll land.
So a bit ago I wrote about the
partiphify method, a part of the morphix library for Elixir. My conclusion was that I wasn’t particularly happy about the code I originally wrote for that method. It seemed clumsy. So I wanted to refactor it. …
I recently lost my full time job. I’m working as a contractor, but one of the things about my life is that I’m legally obligated to have health insurance at all times, so I’m looking for a new full time job, which means I’m also looking at old code that I have hanging around on Github to see if I even know what it does or how it does it.
Happily, for the most part, I do.
Except for one function, which for reasons that are actually reasonable I named
partifify/2 is part of my Morphix library, which is a tiny library of functions to help you deal with Enumerables in Elixir. I started writing it as a port of another library that I wrote several years ago in Ruby, but it’s grown since then into a fairly nice library that a surprising (read, greater than zero) number of people download and use. …