3 ms·

This is neat, it reminds me of Hypothesis which does randomised property-based testing and if it finds a failing edge case it saves it to a database so that it'

This is neat, it reminds me of Hypothesis which does randomised property-based testing and if it finds a failing edge case it saves it to a database so that it's always used in future test runs. That said, I suspect I'd find a similar limitation with this as with Hypothesis. Most of the tests I write aren't for pure functions, or require a fair amount of setup or complex assertions. It's possible to write test helpers that do all of this, and I do, but too much of that means tests that are complex enough to need their own tests, so I think it's important to balance. This is probably specific to my normal work (Python, web services), but I'd suspect applies to a lot of testing done elsewhere.

CloselyChunky 5y ago
> Most of the tests I write aren't for pure functions In response to this, I recommend the "Functional Core, Imperative Shell"[0] talk/pattern. The idea is to extract your business logic as pure functions independent of the data access layer. This pattern allowed me to test large portions of a code base using property tests. This works really well in most cases and gives me much more confidence in the product that will be deployed. [0]: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...
- danpalmer 5y ago
  Thanks I have seen this talk, it's a good one! While the pattern is good to always be striving for, I think it can be too much boilerplate at times. If I've got say 100 lines of business logic, it makes sense to have 10 lines to do the necessary data shuffling to get everything in order so that you can keep your business logic a nice pure function. On the other hand, if you have 5 lines of business logic, it maybe doesn't make sense to have 10 lines of shuffling data to be able to keep the business logic a pure function. Not so much for the time to write it but because it can obscure the functionality for the reader.

CloselyChunky 5y ago

> Most of the tests I write aren't for pure functions In response to this, I recommend the "Functional Core, Imperative Shell"[0] talk/pattern. The idea is to extract your business logic as pure functions independent of the data access layer. This pattern allowed me to test large portions of a code base using property tests. This works really well in most cases and gives me much more confidence in the product that will be deployed. [0]: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...

danpalmer 5y ago
Thanks I have seen this talk, it's a good one! While the pattern is good to always be striving for, I think it can be too much boilerplate at times. If I've got say 100 lines of business logic, it makes sense to have 10 lines to do the necessary data shuffling to get everything in order so that you can keep your business logic a nice pure function. On the other hand, if you have 5 lines of business logic, it maybe doesn't make sense to have 10 lines of shuffling data to be able to keep the business logic a pure function. Not so much for the time to write it but because it can obscure the functionality for the reader.