Why a mock doesn’t work

>Sure but then I have to write my real library code using an abstraction, making my code more difficult to read and maintain

Or easier - as the abstraction can simplify the interface, localize the logic for directory work, make it easier to port, and so on. That's the reason why most of us use "requests" and not urllib, too, for example, or Yoda and not Java's legacy time mess.

>a dependency injection system is then necessary in order to have the correct concrete implementations set up at runtime.

You can write alterative implementations (whether with base class, interface, traits, or what have you) and use them for production code and for testing without any dependency injection.

>Those of us using Python are using it because it is an interpreted, dynamic scripting language.

The abstractions mentioned come from Smalltalk, which arguably is the same or even more dynamic than Python. Having a class/interface/protocol/trait and a test implementation is by no means a static typing/Java thing, or counter to a dynamic language, as implied here...

Agreed with the articles, mocks are very tied to implementation details. I almost always prefer state-based testing:

https://martinfowler.com/articles/mocksArentStubs.html

As "observable state goes from a to b" is much closer to a business/functional requirement that will still/always be true, regardless of refactorings.

Refactoring in codebases with state-based tests is a pleasure; in codebases with mock-based tests it's tedious, constantly updating tests when no semantic behavior was supposed to change.

Also, mocking via module hacks like in the article (and in the JS world) is scary; modules are basically global variables so it's a very coarse grained slice point. Dependency injection is almost always better.

> a dependency injection system is then necessary in order to have the correct concrete implementations set up at runtime.

Dependency injection can be as simple as:

    class Printer:
      def run(self):
        print("hello world")
    
    class Caller:
      def __init__(self, printer_class=Printer):
        self.printer = printer_class()

      def doit(self):
        self.printer.run()

In your tests all you have to do is pass a different object to your Caller class. No need to mess with factories, interfaces or Impl suffixes.

If the point is just having simpler testability and making dependencies more explicit, this gets the job done.

And since Python is a dynamic language, you can use this with stdlib classes too, so it solves your first complaint.

I've seen it a lot in Ruby and C# lately.

Why I don't mock:

https://blog.metaobject.com/2014/05/why-i-don-mock.html

> Dependency injection leads to elaborate, brittle fixtures

I believe that can happen, but personally (N=1) haven't seen it. If anything, (well-done) DI is supposed to prevent that, b/c fixtures are isolated instead of depending on random global behavior.

That said, I also don't like Spring/Guice/Dagger auto-wiring DI (somewhat guessing that is what caused your headaches), and instead just create an "AppContext" type with all of the applications "singletons" and pass that around.

Granted, it's still global-ish, so maybe I'm cheating, but its nicer IMO than module hacks.

> I use mocks to arrange state A without going through > all the business rules involved in creating state A

I like tests being able to immediately jump to state A, but fwiw don't see why mocks would be needed to do so.

I do agree re avoiding test explosion/transitivity, and a few functional happy/sad plumbing tests, but again seems orthogonal to state/mock.

> You end up with elaborate, (often custom), mocks that > couple all of the tests together in hard to maintain ways

Totally agreed. Another -1 for mocks. :-) I.e. with state-based you should be able to test "end-to-end" (with state-based / in-memory stubs for your input/output data stores/etc.) without any of "oh right, copy/paste these 5 lines of 'when method X return result Y' for ~2-5 some mocked-out calls).

(And, to be pedantic, if you mean something other than 'when method X return result Y' for the term 'mock', then we're probably talking about different things.)