So this is a very thorough article. Aside from using unfamiliar terms, nearly every concept is valuable and familiar. I am a big proponent of not mocking / no m

So this is a very thorough article. Aside from using unfamiliar terms, nearly every concept is valuable and familiar. I am a big proponent of not mocking / no mocking frameworks/libraries. 15+ years of building large SaaS systems with hundreds of contributors and optimizing for testing so deployment is the best balance of safe and fast. I use nearly every pattern mentioned to write my tests in Go. I now use the same patterns in Python where I can - this new org is less mature in its testing solution and mocks and spaghetti abound. For similar, Go specific resources look up, "Go fakes vs mocks." Other related reading on reasons to avoid mocks: https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/articles/mocksArentStubs.html fwiw, not a fan of a couple techniques like nullables and prefer Fakes/Fake Constructors, but it is splitting hairs. Overall the message is correct: avoid mocking. Have a way for systems under test to have implementation details changed while interfaces remain the same.