Faking - Dependency vs Internal Details

Question

Just for the sake of discussion below, when I refer to mocking, I mean mocking/stubbing/faking, as contrast to use real implementation in testing

I just had some discussion with my colleague during a pair programming session regarding whether we should use mocking in unit tests for our own written code. (Not sure whether this matters, but we are pair programming on a Ruby/Rails code base)

His argument is that we should not use mocking if it's our own written code. Mocking should be used only to stuffs out external dependencies (.e.g. third party system). Let's say if there are class A and B, and A depends on B (.e.g. one of A's method creates and uses B), he said we should not mock B out when testing A (both A and B are written and maintained by us), since B is internal implementation details of A.

While I agree with him to some degree, I still find some cases where mocking our own code is necessary and required:

• First, I believe if we don't mock dependencies of a class, it's no longer unit test. So like above example, we are writing integration test for class A and B. I'm not saying integration tests are not needed, but there are some disadvantages of it compared to unit test, .e.g. run slower and when a test fails, you need to trace the implementation code to identify the components that cause the failure. And therefore we should make it clear what's unit test, what's integration test
• Second, we should not test and care about implementation details of a class as long as its public contract still maintains. However, I believe we should test a class's interaction with its (peer?)dependencies since those interactions are expected behaviors of that class. In some cases, it's not easy to determine what is implementation details and what is dependency, .e.g. in a layered application (controller -> application service -> domain), is an application service dependency or internal implementation of a controller?

So my questions are:

• What are your opinions on when and where to use mocking?
• Any good heuristics to decide what is dependency and what is internal implementation details? Take for example the layered application above

Not sure whether it's because my background is in C#, I find it difficult to accept the idea of mocking is not needed when testing our own code

Answer 1

His argument is that we should not use mocking if it's our own written code. Mocking should be used only to stuffs out external dependencies (.e.g. third party system)

Mocking should only be used if absolutely necessary as every mock means you are testing how a piece of code behaves when connected to that mock, rather than the real code.

See Stop using mocks, along siwth Mock yourself, not your tests and many more easily searched-for articles on why mocking should be avoided.

Let's say if there are class A and B, and A depends on B (.e.g. one of A's method creates and uses B)

Is B a public class? If so, A shouldn't be creating an instance of B; that's tight coupling. Instead, A should be passed an instance of the interface IB, or IBFactory from which it can request an IB instance. If B is well behaved with deterministic behaviour and no external side effects, then it can even be used directly when testing A.

First, I believe if we don't mock dependencies of a class, it's no longer unit test.

Sorry but that is nonsense. A unit test is a test of a unit of code that can be run in parallel with other tests without affecting those tests and without external side effects. That unit of code could be a function, a collection of functions (eg a class), or nearly the whole system, just so long as it doesn't have side effects or affect other tests.

What are your opinions on when and where to use mocking?

You use mocking only when it can't be avoided.

Any good heuristics to decide what is dependency and what is internal implementation details?

Is the dependency public? If so, then it is not an implementation detail. If it isn't public, then it is indeed an implementation detail, but is also a dependency (and if it's an implementation detail it absolutely should not be mocked as tests shouldn't go anywhere near implementation details.)

Answer 2

There's three good arguments for using Mocks (and by mocks, I mean those items created by a framework like Mocha that allows you to assert whether the mock has been called):

• It is important to know that the object under test correctly and consistently calls the other object in a specific manner and/or a specific number of times.
• It is important to prevent the side effects that may be caused by calling other object methods.
• It is important to isolate the unit of code you want to test in order to pinpoint the cause of failures, much as @Callum points out in his comment on the David Arno's answer.

If you don't care about these items, Mocks aren't really necessary.

Answer 3

C# background here as well. You may want to look up 'mockist' (aka London) approach to TDD (as opposed to classical/Detroit one). I personally have used it with great success in many commercial projects, and found it to be the best way to test my units in perfect isolation. You end up with amazingly decoupled design that way.

Don't listen to people who tell you to rely on integration tests. Integration tests are a scam, because there is no way in hell you'll be able to cover all combinations of edge cases inside the chain of units that your integration test is supposedly testing. Focus on having perfectly tested units, and the whole system will just work when you compose your object graph (I usually throw in a couple integration tests as a sanity check).

I highly recommend the following book, especially the first few chapters that explains the mockist approach to TDD perfectly: Growing Object-Oriented Software, Guided by Tests

As far as your question regarding what to mock? I mock anything that's not under the test. Usually it means mocking the interfaces of the dependencies that are being injected into the constructor of the class that's being unit tested. With C# we have the advantage of having access to Moq, which is not only very powerful, but also very concise and readable.