Mocks & stubs by Ken Scambler

The general strategy is to talk about the *intent* to interact with an external service, which allows you to do much of your testing in these terms; i.e., you usually don't need to test that the email was actually sent, you need to test that the *request* to send an email contains the correct information, which shrinks the surface area of your integration testing. This talk by Ken Scambler explains this strategy very well I think. A generalization of this idea is to abstract the meaning out of your program using `Free`, and providing multiple interpreters. This allows you to swap out production logic for test logic to simulate unusual failures and so on. It's kind of like mocking in spiri…

I think passing around plain old values is simpler, for example: https://github.com/enpassant/miniatures/blob/master/src/main/scala/plainFP/Config.scala "If we have to pass all these config parameters everywhere" (video at 20:22). I think this is a design flaw, that is passing unnecessary state everywhere. For example, readName method depend on Config object (unnecessary state of Config.age). There is a very good talk about it ("clumsy input") by Ken Scambler: link to this video I think the functional DSL solution is simpler than with implicit: https://github.com/enpassant/miniatures/blob/master/src/main/scala/plainFP/Table.scala