Comments on: Putting mocks in their place

By: Vasilio Ruzanni

Vasilio Ruzanni — Sun, 26 Jun 2011 00:08:00 +0000

How about specific implementation when our Command invoker (CommandBus) is returning at least Ack/Nak kind of result (on CommandBus.Broadcast(command) call) so we do always know that Command is being processed?
Probably, we don’t need an AssertWasCalled at all?

By: Uttam Kini

Uttam Kini — Fri, 14 Jan 2011 23:53:15 +0000

I agree that mocks are misused. But I think if used correctly, they can breed good OO and flexible code.
Even for code without external dependencies, if I have a sufficiently complex piece of business logic, then without mocks my unit test becomes a huge suite of integration tests.
Having said that, if I see a unit tests with a lot mock assertWasCalleds then it is a code smell for me, which indicates the class under test is probably doing too much.

By: - Martin

- Martin — Thu, 13 Jan 2011 00:11:46 +0000

I can see wher eyoru coming form but i think you need balance in your assertions about mocking especially in a BDD context i would offer this post as a balancing perspective if i may.

http://martinsharp.wordpress.com/2011/01/09/interface-first-development-and-mocking-overview/

if you would like to discuss please email me on rebeccamartin@me.com

By: derekgreer

derekgreer — Sat, 08 Jan 2011 13:49:50 +0000

@ntcoding

It isn’t that programmer tests never use test doubles, it’s just that there isn’t an emphasis on isolation and therefore real collaborators are used when possible. Collaborators which encapsulate access across a process boundary (such as a repository) would generally be stubbed within a programmer test as well. Perhaps a better example for contrast might be how a class with a calculator dependency might be tested with a unit test verses a programmer test.

By: ntcoding

ntcoding — Sat, 08 Jan 2011 11:45:20 +0000

@derekgreer

That comment you make helps to put things into perspective for me. If I’m right then your essentially saying you can’t have unit tests (that isolate the smallest unit of code) without mocks.

Going back to my comment above, if you mock the repository then you do have a fine-grained unit test. If you don’t mock the repository you have the “XP Programmer Tests” which can cause controller tests to fail if the repository tests fail.

I think we are all looking forward to the next installment. You have built a lot of expectancy now Mr Bogard.

By: derekgreer

derekgreer — Sat, 08 Jan 2011 07:02:05 +0000

It sounds like you’re advocating the use of XP “Programmer Tests” over isolation tests (what most call unit tests). I can see pros and cons with both approaches. Programmer tests are less brittle because they don’t make as much use of test doubles, but they also don’t provide precise feedback about why a test failed (a single regression can result in many tests failing) or force decoupling through isolation. Isolation tests tend to force the designer to program to interfaces, but can be less resilient to change as compared to broader-brush tests.

I currently favor higher level acceptance tests which drive the creation of lower lever isolation tests because I like the specific feedback and the discipline it seems to provide (especially for teams new to TDD/BDD), but I’m looking forward to reading the arguments you present in your follow-up post.

By: Josh

Josh — Fri, 07 Jan 2011 22:34:07 +0000

External dependencies should not be mocked. Any code you do not own or have control over should not be mocked. Where such code is used, integration tests should be used. This is the only way to ensure the uncontrollable code is in fact doing what you expect, and that you code is interacting correctly with it. And you won’t know this if you mock it out.

If you need to separate out this uncontrollable code, you need to use an adapter layer. Integration test the adapter and uncontrollable code by mocking your calling code. You can now unit test your calling code by mocking the adapter.

This info was from GOOS. I really recommend this book.

By: isaiah

isaiah — Fri, 07 Jan 2011 22:13:28 +0000

Hi Jimmy
“Tests coupled to the implementation of the class under test are a barrier to refactoring” if that is the case, the tests are hinting there is a issue with the design, as Rob suggested the GOOS book shows there is another school of thought where mocks are used an aid in designing OO code. one of the key things i got from GOOS book and chatting with steve and nat was distinguishing between internals and peer objects.

By: ntcoding

ntcoding — Fri, 07 Jan 2011 20:04:08 +0000

Please could you show how you would do a typical “create” scenario in say a web app. Let’s say you are creating a “fish” object and saving it to the repository.

Would you mock the repository and assert methods were called? Would you mock only the “data context” for the repository?

Interesting blog post on a topic I have been debating (not arguing about ) with a colleague the last few days.

If you can’t give me an example, then I can only look forward to the next episode.

Thanks

By: John Sonmez

John Sonmez — Fri, 07 Jan 2011 14:27:28 +0000

Keep banging that drum, you are headed the right direction I believe. We overuse mocking and complicate unit tests, mocking only external dependencies seems like the right approach to me.