A very good way to use mocks (not like illustrated here) is explained in the GOOS book by Freeman and Pryce: http://www.growing-object-oriented-software.com/
Can you summarize what that good way look like for those of us that haven't read it ?
Don't Use Mocks
21–30 of 85 posts
Re: Don't Use Mocks
#22This topic of testing techniques is fraught with extreme points of view. The way I see it is that unit testing, int-testing, mocks, stubs, and now fakes are all techniques and tools in your toolbox. Do not throw out a tool in favor of always using one of them. Instead, I implore devs, to try and use the *best tool for the job at the time for a specific test. Understanding that "best" is based on opinions and current constraints at the time. I would implore exploration, and experiments to try these different tools to get a better understanding of their pro's and limitations.
Re: Don't Use Mocks
#23Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.
Re: Don't Use Mocks
#24There are entirely separate communities IMO when it comes to automated tests. There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing. And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to th…
It's all about staying in language though, at least in my opinion. The test suite I don't run is the one that requires the complicated docker compose stack and the local network to look just right. The test suite I do run is the one where I hit "run" in my IDE and then it lets be jump to what failed and debug seconds later. That, IMO, is what mocking is about: making the tests fast and easy to run so they actually ar…
Agree. Mocking is a slippery slope I think.
We need to mock, for example, DownstreamAPI01 that our app POSTS to and GETs from, so we can put in accurate and realistic faked responses.
We don't strictly need to mock other bits of our own apps - but many people choose to do so.
Martin Fowler writes very well about this, and I hadn't even appreciated the "split" between sociable unit tests and solitary tests:
https://martinfowler.com/bliki/UnitTest.html
I can see the appeal of both sides, but (a) I prefer sociable tests as they tend to test real code more than artificial constructs, and (b) people tend to get into a mess when they try to produce pure solitary tests, leading to the "not really testing your app" example in my earlier comment.
Re: Don't Use Mocks
#25The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle. Almost any change in the implementation will require changing such tests. And by their nature, they probably test some minor low-level things, that are not all that valuable to assert anyway. Mocks enable and encourage this kind of testing. Better t…
>This often involves making the dependencies you inject during testing some more complete simulations of real implementations. Takes more up front effort to implement them, but can often be re-used between many tests.
At higher levels, the up front effort is higher but most of that work that is much more reusable - reusable across implementations and different languages, even.
With tools like playwright and MITM proxy, the state of the art for these highly reusable tools has moved forward considerably in the last 5 years. I can now "TDD" everything in a way that actually makes sense on some projects - even a tweak in CSS (via snapshot driven development).
Meanwhile CPU power has also kept accelerating to the point that hermetic end to end tests that were unbearably slow can now be run on a laptop in seconds. Entire suites that used to take hours on CI can be trivially parallelized and run in minutes instead.
Re: Don't Use Mocks
#26The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle. Almost any change in the implementation will require changing such tests. And by their nature, they probably test some minor low-level things, that are not all that valuable to assert anyway. Mocks enable and encourage this kind of testing. Better t…
The tests you propose might take 10x longer to run. There is value in having quick tests as a first level of validation.
Re: Don't Use Mocks
#27This article is extreme, in the case of Java (mockito), using mocks is a great way to infer the path the logic takes. If anything mocking is useful for verifying that something is called whether that be a service or a repository method. Equally mocking things like mappers is overkill, a nice balance is to inject some mocks and some "real" instances of dependencies into the class that is under test. The added benefit…
Verifying that something is called is the canonical use case for a mock. If you're using a mock and it's not doing verification, it's not a mock. It's something else.
Re: Don't Use Mocks
#28Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.
Re: Don't Use Mocks
#29Nah I'm about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.
If you can use sqlite in tests it’s often a good middle ground
Re: Don't Use Mocks
#30I think this one is context dependent. If you are a small or medium project that doesn't make many RPCs just test with the real thing. Once I got to google which makes many RPCs in every layer it just wasn't viable to not use mocking. I use mocks in almost every thing. Yes, it makes unit tests brittle and couples to implementation. But unit tests are cheap and often need to be changed anyways. It also allows you to h…
Do they still have guitar? I thought guitar was a really cool project