You might recognize some of the “sponsors” in this episode. Drop a comment or a like if you do!

I like the tangents. Please keep them coming 👍🏻

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.

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.

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).

Tangent good

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.

There still are a lot of developers around which do not use unit tests.