One of the most transformative pieces of wisdom I’ve gotten in my career is Titus Winters’s ToTW #122 on test dataflow clarity. The Tip of the Week (ToTW) series offers advice focused on C++. Like Testing on the Toilet, which offers advice and best practices for software engineering at Google generally, it has become a fixture within the engineering culture, frequently cited in code reviews.
If you haven’t already, check out ToTW #122: Test Fixtures, Clarity, and Dataflow now — I’ll wait.
At it’s heart, the advice is simple: avoid overusing test setup and helpers to obscure data flow. As a reader of a test, I should roughly be able to understand what goes in and what comes out, without significant context switching, scrolling up and down a large file, or switching between multiple files. This tip follows a theme of best practices on DAMP versus DRY tests.
In this article, I’ll discuss two approaches to clearer data flow in tests that can benefit certain codebases.
Human Readable Inputs and Expectations
Taking the advice from ToTW #122 a bit further: we can do a better job at further clarifying the data flow by inlining a lot of the data construction.
Take this example, which already follows some of the advice from the tip:
