You might recognize some of the “sponsors” in this episode. Drop a comment or a like if you do!
@sp3ctumАй бұрын
I like the tangents. Please keep them coming 👍🏻
@BookOverflowPodАй бұрын
Thanks for the feedback! See, other viewers? This is how you engage with the podcast!
@MichaelSchuerigАй бұрын
Around 26:30: injecting a dependency into a constructor is called Dependency Injection. If a component (itself!) defines interfaces for things it depends on, instead of depending on a concrete implementation of those things, that is called Dependency Inversion. An implementation of a dependency for testing purposes is called a Test Double. A Mock Object is a Test Double with the more specific function that the Mock Object verifies how its methods are actually called against how it expects them to be called. In contrast, a Stub Object is a Test Double that simply supplies canned values.
@MichaelSchuerigАй бұрын
As Bertrand Meyer is mentioned 41:50, you might want to have a look at his Object-Oriented Software Construction. Another one of the classics. Preferably the first, 1988, edition, instead of the later tome with double the size. This book is the original source of the Open/Closed Principle as well as Design by Contract. Also, it introduced the Eiffel programming language.
@juancruzdelatorre7923Ай бұрын
Great video, as usual! I've been thoroughly enjoying this podcast, as I've very recently read some of the books you've discussed so far. I also love the fact that you touch on the overuse of the term "mock." However, and I hope this doesn't come off as pedantic, I don't see eye-to-eye with Nathan on his characterization of the difference between mocks and fakes (perhaps I consider what he's describing as a fake to be closer to a stub?) Quoting Martin Fowler on "Mocks Aren't Stubs," mocks are "objects pre-programmed with expectations which form a specification of the calls they are expected to receive." That is, you must pre-define all of the expected method calls for an object along with their expected return values. On the other hand, fakes usually "have working implementations, but usually take some shortcut which makes them not suitable for production." This means you do not need to pre-define the expected method calls and their return values; instead, you provide an implementation that does just the bare minimum for what you're trying to test. (i.e.: you could provide a fake which implements a barebones version of the real object, or one that returns authorization errors or simulates network faults or timeouts if that's what you need!) I believe one should take care to use the type most appropriate for what you're trying to test. For instance: - Do you need to assert that a specific method was called a given number of times with certain arguments? For example, you might want to do this if the method call has side effects that can't be measured from the point of view of the unit you're testing. If this is the case, perhaps you should consider using a mock. - Are you calling multiple methods of an object that maintains some sort of internal state? For example, you might be doing this if you're calling an external API or database to create, update, and retrieve records. If this is the case, perhaps you should consider using a fake. I'm sure there are more examples, and of course, these specific types of test doubles are not suitable for all testing requirements! But in particular, I've seen lots of legacy code (!) with very brittle tests due to using mocks for certain testing dependencies and failing to realize that the mock responses are not consistent with each other (or they are no longer a faithful representation of the real object). In those specific cases I encountered, I argue a fake would've been a better candidate for a test double (alongside appropriate unit tests to verify that the fake is correctly implemented).
@nathantoupsАй бұрын
Hi! Nathan here. I appreciate your thoughtful comment, and I must admit that I oversimplified mocks vs. fakes in my examples. I agree with you that they are context-specific, and fakes can be complex, for sure. Thanks again for adding to the conversation, it is participation like this that makes this content even richer.
@rad_cheedАй бұрын
Tangent good
@samueltremblay275Ай бұрын
There is a lot of glitch in the video. First I was thinking the cause was my internet connection but after watching other videos, I found this is only this one. But no matter what, the content is great.
@BookOverflowPodАй бұрын
@@samueltremblay275 We are definitely professional software engineers, not professional podcast editors haha. We’ll try to keep these glitches a one time thing!
@rainerblessing923Ай бұрын
There still are a lot of developers around which do not use unit tests.
@nathantoupsАй бұрын
Sad, but true.
@BookOverflowPodАй бұрын
I think many don’t understand the purpose. While they’re useful for catching bugs pre-deployments, their much bigger value IMO is allowing you to refactor with confidence.
@rainerblessing923Ай бұрын
@@BookOverflowPod Luckily there are smart IDEs which understand the code structure well enough to do some refactoring without tests. But if you are using a restricted IDE like eclipse you do not dare to break up functions into smaller ones which leads to functions with huge cyclomatic complexities which are several hundered lines long like in our projects 😢.