Two common principles for writing good tests are:
1. Make them *scannable*. Scannable tests make it easy to quickly see what a module is for (if you're trying to understand it) and can better remind you of special design cases (if you're going to change it).
2. Make them *focused* by avoiding any words not relevant to the purpose of the test. Focused tests are usually more maintainable. But, more importantly, they can help programmers think about the problem to be solved and the design that solves it.
In the talk, I won't argue for those principles at any length. Rather, I'll show them in action by converting some typical Phoenix tests into scannable, focused tests. I'll speak about some subset of these topics, all of which I find useful:
- pipelining assertions
- using a broader set of general purpose assertions tailored to, for example, map structures and changesets
- domain-specific languages for setup
- tabular formatting
- separating out special cases into a ""cabinet of curiosities"" that showcases exemplary data
- the importance of team style and habits
- the use of Boyd Multerer's PhoenixIntegration library to simplify unit tests
I highlighted `PhoenixIntegration` above because my goal is not just to show principles in action but to provide pointers to code ready for use or copying.