Quickest way to get a test suite so tightly coupled to structure rather than behavior that even just looking at the tests wrong makes them fail. But technically you do get test coverage I guess. Goodhart’s law in action.
Oh I’m fully aware that python lets you cheat dependency injection with patch, its one of the many things python teaches developers to do wrong, which leads them to be unable to use any other language.
While my experience is mostly C++, I assume these mocking libraries are similar in allowing you to create a class that can report it’s own usage, and allow for arbitrary returns values and side effects, which is incredibly useful, especially in conjunction with dependency injection.
What patch lets you do is directly overwrite the functionality of private member functions on the fly, which if Java/JavaScript can do I’d love to know, I thought this was a uniquely Pythonic magic.
I feel like there are two concepts be at confused here. ‘Mocking’ is just replacing an actual implementation with one that reports its usage, so calls or lack thereof can be asserted to occur, and tests can fail if that condition is not met. They usually allow setting side effects and return values on a per call basis also, to inject different behaviours for covering different code paths easily.
The question is then how do I get a class like DatabaseWrapper to call into an underlying mockDB instead of the normal realDB? The answer, in static languages is dependency injection: the db object must be constructed externally to the wrapper, and passed in in such a way that any object with the same interface is acceptable.
This allows the tests to pass in a mock with the same interface, and have the class being tested accept it. The class will then run as usual when its methods are called, but we can make assertions about how it uses its dependency. In some languages, such as python (and it seems JavaScript as well) this can be bypassed by monkey-patching the private member dynamically after the object has been constructed to be the mock instead of the real.
Personally, I don’t think this leads to good design. Dependency injection also allows for a nice port and adapter pattern, were in the future we might replace our SQL database with a MongoDB one, and we have to rip up the application, instead of just implementing a new db class that meets the interface, and injecting that into the wrapper instead.
Junior devs not abstracting anything and now the app is unmaintainable
Exactly, have fun trying to get test coverage without dependency injection
with patch("some_file.requests.get", side_effect=SomeException("oh no")): result = func_using_requests()Though not every language makes mocking as easy, and multiple responsibilities in a single function can quickly get messy.
Quickest way to get a test suite so tightly coupled to structure rather than behavior that even just looking at the tests wrong makes them fail. But technically you do get test coverage I guess. Goodhart’s law in action.
Oh I’m fully aware that python lets you cheat dependency injection with patch, its one of the many things python teaches developers to do wrong, which leads them to be unable to use any other language.
I vaguely remember Java also has mocking libraries, as does JavaScript. (Though JavaScript isn’t a language I’d hold up as the ideal.)
While my experience is mostly C++, I assume these mocking libraries are similar in allowing you to create a class that can report it’s own usage, and allow for arbitrary returns values and side effects, which is incredibly useful, especially in conjunction with dependency injection.
What
patchlets you do is directly overwrite the functionality of private member functions on the fly, which if Java/JavaScript can do I’d love to know, I thought this was a uniquely Pythonic magic.Javascript has mocking with jest: https://jestjs.io/docs/mock-functions
There’s an example there of mocking our axios (a common library for network requests, a la python requests)
It’s been a long time since I’ve used java, but mockito exists: https://site.mockito.org/javadoc/current/org/mockito/Mockito.html#2
(Usage note for anyone unfamiliar, but despite the name java and JavaScript are radically different languages.)
I feel like there are two concepts be at confused here. ‘Mocking’ is just replacing an actual implementation with one that reports its usage, so calls or lack thereof can be asserted to occur, and tests can fail if that condition is not met. They usually allow setting side effects and return values on a per call basis also, to inject different behaviours for covering different code paths easily.
The question is then how do I get a class like DatabaseWrapper to call into an underlying mockDB instead of the normal realDB? The answer, in static languages is dependency injection: the db object must be constructed externally to the wrapper, and passed in in such a way that any object with the same interface is acceptable.
This allows the tests to pass in a mock with the same interface, and have the class being tested accept it. The class will then run as usual when its methods are called, but we can make assertions about how it uses its dependency. In some languages, such as python (and it seems JavaScript as well) this can be bypassed by monkey-patching the private member dynamically after the object has been constructed to be the mock instead of the real.
Personally, I don’t think this leads to good design. Dependency injection also allows for a nice port and adapter pattern, were in the future we might replace our SQL database with a MongoDB one, and we have to rip up the application, instead of just implementing a new db class that meets the interface, and injecting that into the wrapper instead.
Is it any more maintainable with four levels of abstraction?
There’s a middle ground
Not on the internet!! How else will we learn to hate each other?!
2 layers of abstraction is the gold standard
Depends on the abstractions