|
|
|
|
|
|
by CloselyChunky
1861 days 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/funct... |
|
|
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.