Think About this Before Creating a New Mock

No video

Think About this Before Creating a New Mock

Рет қаралды 2,973

Күн бұрын

Join me as I show you the dependencies that need a Test Double and the ones that don't.
💎 Be a Patreon to get the source code: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
💌 Free Developer Insights: guiferreira.me...
📘 Courses: guiferreira.me...
👨‍🏫 Workshops: guiferreira.me...
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsf...
Get my newsletters: guiferreira.me...
Visit my blog: guiferreira.me
👋 WHO AM I
Hey! If you're new to my Channel, I'm Guilherme. Call me Gui. I'm a Minimalist Software Craftsman. What do I do here? I share tips on how to simplify your life as a Developer.
🎵 MUSIC CREDITS
Blue Mint Road / StreamBeats / Lofi
#dotnet #csharp #softwareengineer

Пікірлер: 21

@davemasters 3 ай бұрын

I love finding videos like this that vindicate my approach and thinking. This video is *exactly* how I approach testing. The "prequel" to this video should be Ian Cooper's brilliant talk, "where did TDD go wrong".

@gui.ferreira 3 ай бұрын

Thanks, David! Glad if you find it interesting. That's a great talk!

@Rick104547 3 ай бұрын

Love this. Good to see more ppl are writing sensible tests like this instead of mockeries. Doing this correctly gives you so much freedom to refactor!

@gui.ferreira 3 ай бұрын

Thanks for your comment. Usually, this is not an opinion that gets much love 😅

@SlowAside5 3 ай бұрын

I agree with basically everything you said here. One thing I haven’t figured out in my own TDD practice, though, is how do you test internal dependencies that have somewhat complicated logic? I’d rather not mock them for the reasons you explained here. However, they might be awkward to test since the original unit test may be far removed from them. What I end up doing is creating mocks for them, along with separate test classes that test them directly. It’s not ideal but it seems like an acceptable trade off.

@gui.ferreira 3 ай бұрын

Awesome question. I don't test internal dependencies. I only test through the public contract. From your description (not knowing the details) if the dependency doesn't touch the outside world (it's just logic) I would use it. I would also question if it would improve the design promoting that internal dependency to Public, and directly test it. Let me know if this isn't clear.

@SlowAside5 3 ай бұрын

@@gui.ferreira Yes, I ended up making it public. The internal dependency was a bunch of validation logic that seemed daunting to implement at the time, so I deferred the work on that by introducing a mock for it. After I was finished with the main system under test, I moved on to implement the tests and logic for the validations. My understanding is that this approach is pretty much the London school of TDD. I prefer the Detroit school where possible but in this situation the London school helped me make progress.

@barberaf 3 ай бұрын

Do you think that DBs need mocks? In my opinion they are under our control, so they don't going to produce unpredictable behaviours.

@gui.ferreira 3 ай бұрын

That's a great point, Francesco. Vladimir Khorikov segregates dependencies between Managed and Unmanaged. The database, in your example, is a managed dependency (assuming no one besides your application can touch it), so it's fair to argue that it's an implementation detail and mocking it will lead to brittle tests. If you mostly write "Integration Tests", this is a valid point of view. I like that approach if I'm doing a simple API over Data (not much logic to be tested). However, if you strive for an extremely fast test suite, those real dependencies can become a problem. For instance, if you practice TDD.

@jewersp 3 ай бұрын

I'm not a huge fan of using mocking frameworks, either. However, they're still useful in many situations. What I don't like is when fakes need to have logic, because that's not directly part of the test or test setup. Overall great advice, Gui!

@gui.ferreira 3 ай бұрын

Agree. If the Fake has logic, it's hard to trust them. I only use them if I can keep them "dumb".

@Rick104547 3 ай бұрын

This really depends on the promise the contract makes though. There are cases where this promise is clear and a simplified fake that mimics the real thing in memory is far more productive than mocking it in every test. For instance you have an interface that promises to store a item. One could simply implement this in memory with a List. I done this for a interface where the real implementation used cosmosdb which made it so easy to test our code compared to mocking it every time.

@jewersp 3 ай бұрын

@@Rick104547 You can share mocks and reset them and reduce the per-test overhead, but I agree that there are situations where a fake might be the better choice, indeed.

@BTimelessC 3 ай бұрын

In which folder would you put the fakes in? Would it be in a fakes folder in each unit test folder or different folder structure?

@gui.ferreira 3 ай бұрын

If the fake will be shared across multiple test classes of the same folder, I generally have a TestDoubles folder.

@BTimelessC 3 ай бұрын

@@gui.ferreira Thank you!

@KritX01 3 ай бұрын

I understand that you don't like mocking frameworks. But why? Why the hassle of creating a fake when a mock does just the same?

@LewisCowles 3 ай бұрын

They explained that it does not do the same, and can lead to difficulties refactoring tests from a concrete implementation detail obsessed towards more interoperable components.

@KritX01 3 ай бұрын

@@LewisCowles he said that for the other mocks. Not for the fake repository. He just said he didn’t like them. I don’t think that by making the fake repository you gain much when you can use a mock there

@gui.ferreira 3 ай бұрын

Great question. I prefer to use Test Doubles over a Mocking Framework mostly because of all that comes with the dynamic definition of a mocking framework. I find Test Doubles easier to read than Mocks. They improve clarity. The Mock expectation programming can make tests brittle. If you are not careful enough, they can lead you to naturally test implementation details over behaviour. I don't say "don't use mocks". What I mean is that usually, a Test Double is the best solution. Mocking Frameworks are a Swiss Army Knife. They can do anything, but sometimes there are better tools for it.

@sunnypatel1045 3 ай бұрын

Could you do more videos on test doubles vs fakes