I do stand by that comment. In the (current) preface I mention that I’ve spent years toying with property-based testing [on and off] without feeling competent. I’ve seen talks about it, asked questions to people who knew more than I do, and a lot of the examples – toy examples – always felt very limited or always highlighting some basic bug (0.0 =/= 0 but Erlang allows both!) Stateless tests are fairly okay to test, but stateful ones were more of a challenge.
Eventually I decided to take a deep dive and test non-trivial projects with it [albeit personal toy projects] until I could find ways to deal with asynchronous code, complex outputs and inputs, and figure out, with limited outside help, what seemed to stick or not.
I’m hoping that this ‘book’ helps share my experience and therefore makes the investment required lower, but truth is that there is a kind of habit that you get in “thinking in properties” similar to what you get in programming languages or specific paradigms, and that takes practice. There are tips and tricks, but you only think comfortably within a paradigm once you’ve forced yourself to hit and go through a few walls with it.
but truth is that there is a kind of habit that you get in “thinking in properties” similar to what you get in programming …
I find that the things that make good contracts also happen to overlap with good properties to test. That doesn’t solve the “properties are hard”, but does reframe the problem in a way that’s often, in my (rather limited) experience, easier to reason about.
`[Property-based testing] is a high-investment, high-reward kind of deal.’ I can’t think of a more Erlang-y notion than that (in a good way).
I do stand by that comment. In the (current) preface I mention that I’ve spent years toying with property-based testing [on and off] without feeling competent. I’ve seen talks about it, asked questions to people who knew more than I do, and a lot of the examples – toy examples – always felt very limited or always highlighting some basic bug (0.0 =/= 0 but Erlang allows both!) Stateless tests are fairly okay to test, but stateful ones were more of a challenge.
Eventually I decided to take a deep dive and test non-trivial projects with it [albeit personal toy projects] until I could find ways to deal with asynchronous code, complex outputs and inputs, and figure out, with limited outside help, what seemed to stick or not.
I’m hoping that this ‘book’ helps share my experience and therefore makes the investment required lower, but truth is that there is a kind of habit that you get in “thinking in properties” similar to what you get in programming languages or specific paradigms, and that takes practice. There are tips and tricks, but you only think comfortably within a paradigm once you’ve forced yourself to hit and go through a few walls with it.
I find that the things that make good contracts also happen to overlap with good properties to test. That doesn’t solve the “properties are hard”, but does reframe the problem in a way that’s often, in my (rather limited) experience, easier to reason about.