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%20Dum... and 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_t...)

3. Virtual services/simulators (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-virt...

Other options available for decoupling from test dependencies:

1. In-memory database https://en.wikipedia.org/wiki/In-memory_database

2. Test container https://www.testcontainers.org/

3. Legacy in a box https://www.thoughtworks.com/radar/techniques/legacy-in-a-bo...