Good Elixir TDD resources?

Aspect: Testing as One Driver of Design

My exposure to property testing is minimal (e.g. worked through an elaborate a QuickCheck demonstration in Haskell) and for the time being Elixir Forum Property-Based Testing with PropEr, Erlang, and Elixir is a bit of a specialist topic for me to fully commit - but the reason it is staying on my radar is that I suspect that beyond the primary benefits it may impose beneficial design pressures on the code.

you find a rule that dictates the behavior that should always be the same no matter what sample input you give to your program, and encode that into some executable code—a property.

  1. In order to use property based testing the STU has to be designed against somewhat coherent (and explicitly stated) rules that the tests can be based on (now if the same was only true for “business” logic). So if you want to leverage property based testing it seems the need for “rules” improves coherence. The flip side is that if you can’t be bothered to discover/refine those “rules”, you are not going to see the value in property based testing. With example based testing there is never any real incentive to unify fragmented, incoherent logic.

  2. While this rant states that “You Don’t Need Referential Transparency” I’d be inclined to believe that property based testing would drive you towards preferring referential transparency.

However I still see property based testing as a rather specialized tool in the “testing” part of software development, likely useful for micro tests, possibly useful with collaboration tests, likely not appropriate for contract tests.

Some approaches to testing can be inefficient/ineffective (similar to the situation in process and documentation). Hypothetically property based testing should be more efficient than example based testing because it can cover more values with less effort. But the issue is that it can’t replace example based testing.

Given that developers will be exposed to example based testing first (and testing is a means to an end, rather than an end in itself - unless you are specializing in testing) they may never get exposed to property based testing.

Then there is the possibility that property based testing is only applicable and effective for code bases that already meet certain quality standards.

Which begs the question: could some software benefit from being “perfected” (i.e. designed) to be more amenable to property based testing and would that improve the software’s design from functional and maintenance perspective?

1 Like