How to AVOID Mocking Frameworks
ฝัง
- เผยแพร่เมื่อ 27 ก.ค. 2024
- How to use Test doubles (Dummies, Stubs, Spys, Mocks, and Fakes) in C# to avoid the complexity trap of Mocking Frameworks.
💎 Be a Patreon to get the source code: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
👋 HEY FRIEND
If you're new to my Channel, my name is Guilherme, but you can call me Gui if Portuguese pronunciation is not your thing.
I see myself as a Minimalist Software Craftsman. That says a lot of what I talk about here.
So, why this TH-cam channel? To share with you to simplify your life as a Developer through knowledge, technology, and practices.
If you are into those things as I do, don't forget to subscribe for new videos.
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsferreira
Visit my blog: gsferreira.com
#dotnet #csharp - วิทยาศาสตร์และเทคโนโลยี
Tried them all, but sometimes the mocking frameworks have done all the heavy lifting.
And those mocking frameworks are likely to be correct, you've just added a whole bunch of new types which are assumed to be correct, but are not necessarily so.
Can't we say the same for many mock configurations?
@@gui.ferreira In your video, you've built all the logic which is typically part of the mocking libraries - how do you know this logic is correct? Tests for test code? Even seldom used mocking libraries may have a 1000 active users, which is probably 998 more than the self coded stub/proxy/mock/fake, and less likely to introduce bugs into your test code. Whilst mocking libraries aren't perfect they do serve a purpose, particularly in complex solutions and/or those with deep stacks (not everything is a simple CRUD API or function).
@@jimiscott I get that. What I mean, is that most problems with Mocking libraries don't come from the library itself, but from the inherent complexity of configuring them in some cases.
@@gui.ferreira Whilst there is some additional complexity required in wiring up complex test cases with a mocking library, that complexity almost always needs to live somewhere - which poison do you pick?
And - At least in my case would prefer that complexity to live in test method (or at least in the same type) than creating my own set of types which need to implement the range of features I may require: number of invocations, value of arguments, easy injection of return values (everything a good mocking library should do) as opposed to writing all of this myself, over and over again.
Finally, I have just gone through a rewrite of some complex test code where we had some of our own types acting as mocks/fakes/etc and they sucked. The tests sucked since the mocks didn't have enough functionality and they sucked as there was an issue with the mock. Rewritten using a mocking library meant better tests and isolated test logic.
Interesting way of testing :) It can also lead us to better define our Mocks, Fakes, Stubs, Dummies and Spy with common Mocking library that are already handling it behind the scene :D
At first, it sounds strange if you are used to a mocking library, however, I find it most effective.
Meszaros defines State Verification as "State Verification (462): We inspect the state of the SUT after it has been exercised and compare it to the expected state.". So both mocks and spies do behavior verification. Other test doubles do no verification at all AFAIK.
Interesting... I would not consider mocks or spies as the SUT.
Once again, you triggered the curiosity in me.
@@gui.ferreira I think the matter migh've got slightly confusing around the time when Mark Seemann started his series on "state based testing", where he describes state-based testing similarly to your description in the video.
Terminology is to a degree a matter of preferrence so no wonder there are some disconnects. Just wanted to point this out because you already used Meszaros terminology in the video, so I though it might make sense to provide this perspective.
Btw, I said other test doubles are not used for verification, but of course they can be. In your video, you used a fake for assertions, which is fine. What I meant is that it's slightly beyond the goal of the pattern itself, since Meszaros writes:
"A Fake Object is quite different from a Test Stub or a Mock Object in that it is neither directly controlled nor observed by the test. The Fake Object is used to replace
the functionality of the real DOC in a test for reasons other than verification of indirect inputs and outputs. Typically, a Fake Object implements the same functionality
or a subset of the functionality of the real DOC, albeit in a much simpler way. The
most common reasons for using a Fake Object are that the real DOC has not yet
been built, is too slow, or is not available in the test environment. "
Right now my company pushing us to use fakes. End of the day if you testing behaviour and verifying your dependencies. Mock is the way testing your dependencies. Adding fakes you adding more dependencies to your code base.
Why do you say that adding a fake is "adding more dependencies"? Because it's a new implementation?
@@gui.ferreira yes also maintaining. You can argue the fact if you have modular monoliths fakes can be useful as you do in memory ef etc.
The question is do we care? If you testing the suit behaviour and got the right assertions then that should give any devs confidence in the code base. It comes down to Chicago vs London style.