Any unit testing library makes it easy to build your own custom assertions on top of the base assertions: just write functions. Often, though, you lose important information like appropriate line numbers, output that highlights structure differences, and so on. ExUnit makes it fairly easy to keep those, but you

A not-infrequent response to my skeptical essay [https://www.crustofcode.com/a-reluctant-rebuttal/] on property-based-testing (PBT) is that I left out an important benefit: it makes you think about properties. (I think "invariant" would be a more precise word, but I'll stick with the standard "property".) That response appeals to me

In a  post [https://buttondown.email/hillelwayne/archive/why-property-testing-finds-bugs-unit-testing-does/] , Hillel Wayne [https://hillelwayne.com/] misunderstands my argument about (not necessarily against) property-based testing (PBT). My fault for talking about it on twitter. Here I’ll try to start the discussion I’ve been wanting to have for a long time.

TL;DR: I introduce assert_fields and assert_copy and provide their code. ( Updated 2019-12-22 with a new syntax for assert_copy.) -------------------------------------------------------------------------------- I  used to say "All the words in a test should be about the purpose of the test." I'll probably be exploring some of the ramifications of

TL;DR: Chain assertions for scannability. Here's some code [https://github.com/marick/crit19/blob/5a8605cf6ef6d7fda3debb4aba281b97e7976946/test/support/assertions/defchain.ex] to help. -------------------------------------------------------------------------------- I suspect tests are more often scanned than read. When a test unexpectedly fails, I think people often jump to its source. But they don't read