All of these basically go the opposite way of the article's philosophy:
Not too many integration tests, mostly unit tests. Clearly define a contract between the boundaries of the code, and stub/mock on the contract. You'll be left with mostly pure functions at the leaves, which you'll unit test.
Thanks for the links, they make sense - I've always had trouble with blind "you should unit test" advice, but especially the video explains the reasoning very well :)
- https://github.com/testdouble/contributing-tests/wiki/London... (and the rest of the Wiki)
- http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-d...
- Most of the screencasts and articles at https://www.destroyallsoftware.com/screencasts (especially this brilliant talk https://www.destroyallsoftware.com/talks/boundaries)
- Integration Tests Are A Scam: https://www.youtube.com/watch?v=VDfX44fZoMc
All of these basically go the opposite way of the article's philosophy:
Not too many integration tests, mostly unit tests. Clearly define a contract between the boundaries of the code, and stub/mock on the contract. You'll be left with mostly pure functions at the leaves, which you'll unit test.