Preface
An argument for the idea
Many people have noticed that a lot of programming–especially functional programming–involves taking structured data, transforming it, producing a result, and possibly persisting that result (to, for example, a database).
Because of that, we work a lot with libraries (like Phoenix or Ecto) that help in writing such transformation code. But we generally take less advantage of that when testing or test-driving such code. That is: the product code we write is clichéd, full of recognizable idioms, patterns, and names. We build on that. But test code doesn't take similar advantage of the structure of the problem. In these pages, I'll describe test code that does.
Such test code can be simpler–more declarative–than the code it's testing. The reason is that conventional[1] test code is essentially a list of specific examples, together with results checking that's specific to the examples. Product code must handle all possible inputs, which is more work. In particular, product code is "branchy", whereas that's vanishingly rare in test code.
[1] I'm going to leave aside generated or property-based tests like PropCheck. Because they don't have a fixed set of inputs, their checks have to be more general-purpose, though still not as complicated as product code.
A Teaser
A whole lot of assertions are generated from this:
Last updated