Ned's implicit definition of a mock is narrower than the generally accepted one. He actually described a stub created by monkey-patching. A mock allows for cal

Ned's implicit definition of a mock is narrower than the generally accepted one. He actually described a stub created by monkey-patching. A mock allows for call verifications as well. There are 3 main categories of techniques for managing dependent components used these days: 1. In-process class/method/function mocks or stubs (http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dum... and https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/articles/mocksArentStubs.html) 1a. By monkey patching (which is what Ned has demonstrated in his article very well) 2a. By dependency injection 2. Over-the-wire API mocks or stubs (https://en.wikipedia.org/wiki/Comparison_of_API_simulation_tools https://en.wikipedia.org/wiki/Comparison_of_API_simulation_t...) 3. Virtual services/simulators (https://en.wikipedia.org/wiki/Comparison_of_API_simulation_tools https://en.wikipedia.org/wiki/Comparison_of_API_simulation_t...) It's worth keeping in mind that all of them are part of a wider group of test doubles: https://www.infoq.com/articles/stubbing-mocking-service-virtualization-differences/ https://www.infoq.com/articles/stubbing-mocking-service-virt... Other options available for decoupling from test dependencies: 1. In-memory database https://en.wikipedia.org/wiki/In-memory_database https://en.wikipedia.org/wiki/In-memory_database 2. Test container https://www.testcontainers.org/ https://www.testcontainers.org/ 3. Legacy in a box https://www.thoughtworks.com/radar/techniques/legacy-in-a-box https://www.thoughtworks.com/radar/techniques/legacy-in-a-bo...