When should I mock or not mock external/dependent public interface

Question

I am trying to write unit test for the following class

I was wondering if I need to mock the Dependency class (consider that it is purely logic no DB or external rest calls are made).

I was thinking if I will not mock the Dependency class, then anyway it will be covered by the CUT or should I mock it and write separate unit test suite for Dependency class public interface.

public class ClassUnderTest { @Autowired private Dependency dependency; public Object foo(){ // do something var = dependeny.bar(args..); // do somethig } }

public class Dependency { public Object bar(args..){ // do something } }

It depends on what Dependency is. And given your example is arbitrary, it is unanswerable. — Michael
– Michael, Commented Oct 27, 2020 at 11:09
@Michael I'm clear and "makes sense" with the answers given to this question, but still I would love to know your thoughts, idk if this could help but my Dependency class is a simple class which performs bunch of jolt transformations. — flash
– flash, Commented Oct 27, 2020 at 11:26
Take a look at my answer to another question that might also be helpful. — pirho
– pirho, Commented Oct 27, 2020 at 12:12

amseager · Accepted Answer · 2020-10-27 10:55:01Z

The main idea of unit testing is to test units separately. Otherwise, it would be an integration test.

In this case, you need to write a separate test suite for Dependency, and mock the call to it in ClassUnderTest.

Alberto S. · Accepted Answer · 2020-10-27 11:02:44Z

If you're writing your unit test suite you probably want to mock it, even more if your dependency is pure logic. Consider the following scenario

public class ClassUnderTest { @Autowired private Dependency dependency; public int doSomething(int a, int b) { return dependency.add(a, b) * 2; } } public class Dependency { public int add(int a, int b) { return 0; // bug here! } }

In your unit test, you'll have something like

@Test void testingClass() { assertThat(classUnderTest.doSomething(2, 2), is(equalTo(8))); }

which will fail. However, your class under test is working fine! It's just delegating the task to another class

You can avoid this false positives by mocking properly your dependencies

@Test void testingClass() { when(dependency.add(any(), any()).thenReturn(10); assertThat(classUnderTest.doSomething(2, 2), is(equalTo(20))); }

mangalores-x_x · Accepted Answer · 2020-10-27 11:02:45Z

You have two separate question.

The point of mocking is to not have dependencies in your unit tests creating implicit behavior. You want unit tests to be explicit about the code unit you test to be able to identify regression and also declare your expectation how ClassUnderTest behaves in different conditions.

Whether you need to cover Dependency is a question concerning your coding standards. In general I find if a class is so simple that you ponder whether you need to test it, then usually writing the test should be a none issue and if writing a test is an issue to me that often enough indicates you really should have a test there, given you are unsure precisely because that code region is opaque.

Collectives™ on Stack Overflow

When should I mock or not mock external/dependent public interface

3 Answers 3

Comments

Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

Comments

Comments

Comments

Linked

Related