Preface
An argument for the idea
Last updated
Was this helpful?
An argument for the idea
Last updated
Was this helpful?
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 or ) 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.
A whole lot of assertions are generated from this: