[matt7340]

My experience with junior (and sometimes not junior) developers has been that the lack of understanding leads to confusion about what they're trying to test. I think the ambiguity leads to a tendency toward mocks, which leads to tests that are focused on collaboration and implementation rather than output. Sometimes that makes perfect sense, but I've also seen where it encouraged more tests that are too implementation reliant.

Nothing wrong with mocks of course, sometimes they are absolutely required. I just favor isolation using stubs, and using mocks sparingly and only when absolutely needed.

> ...in reality every mock needs to act as a stub I disagree. In fact a collaborator method call that doesn't return a value is a great candidate for mocking. Conversely, a collaborator that does return a value can usually be stubbed.

> ...when you stub you can also go ahead and add code to verify some behaviors (mock) to get some extra coverage Entirely dependent on context of course, but to generalize, this feels risky. In many cases adding extra coverage via mocks might be making tests more brittle, for little to no value gain. Further if every method you mock is returning a preset value, there's no reason to verify expectations on it, because it's a stub that will allow verifying expectations on the output of the object/function under test.

As far as library naming, it's just a pet peeve stemming from "mock" somehow becoming synonymous with "test double". If people use a "mocking" library for stubs... well... that's good! :)