How to find out if a method is called on the module under test?

Question

I am writing a new class ( Derived ), in TDD, using mockito, and I have the following case:

Base Classes:

 public abstract class Base<T>{ //....... protected final T baseCreate(T entity){ // implementation } } 

Derived class (this is the class I'm writing using TDD):

 public class Derived extends Base<MyObject> { //....... public MyObject create(MyObject entity){ baseCreate(entity); //This is what I want the implementation to be } } 

When I came to write a test, it will force me to call the baseCreate method - I did not understand how to do it. Is there a way to use mockito to verify that the create(...) method in Derived calls the baseCreate(...) method in the Base class?

Thanks.

Answer 1

Unit tests should check the behavior of the class, not its implementation. Therefore, you should not worry that Base baseCreate() is called explicitly, but rather, the Derived cerate() call is done exactly as you would expect from an external observer perspective

Answer 2

Attila is right for most cases. What you want to test is that the creature really does what you think it should do, not how it does it. The case that you have here is: "I already know that baseCreate does what I want it to do, so I don’t want to repeat it just to be called." It may be so, but if so, then your superclass really collaborates more. This is one of the reasons for the delegation to inherit. However, it is sometimes difficult to go back and change this design decision, so you need to check what you have.

You still prefer to simply verify that "create" does what you want in general, but you might have a case where baseCreate really does a lot of things that require a lot of collaborators and such that makes it difficult and fragile to tests. In this case, you would like to use "spy". The spy wraps the "real" object and delegates calls to the real method, unless you specifically create another wait.

If you can make baseCreate public, you can use Mockito as follows:

 @RunWith(MockitoJUnitRunner.class) // We prepare PartialMockClass for test because it final or we need to mock private or static methods public class YourTestCase { @Spy private Derived classUnderTest = new Derived(); @Test public void privatePartialMockingWithPowerMock() { MyObject myObject = new MyObject(); when(classUnderTest.baseCreate(myObject)).thenReturn(myObject); // execute your test classUnderTest.create(myObject); verify(classUnderTest).baseCreate(myObject); } } 

If you cannot make baseCreate public, I think you could use PowerMock . It allows you to test private methods, but I don’t think that for some reason it could not protect methods.

 @RunWith(PowerMockRunner.class) // We prepare PartialMockClass for test because it final or we need to mock private or static methods @PrepareForTest(Derived.class) public class YourTestCase { @Test public void testCreate() { Derived classUnderTest = PowerMockito.spy(new Derived()); MyObject myObject = new MyObject(); // use PowerMockito to set up your expectation PowerMockito.doReturn(myObject).when(classUnderTest, "baseCreate", myObject); // execute your test classUnderTest.create(myObject); // Use PowerMockito.verify() to verify result PowerMockito.verifyPrivate(classUnderTest).invoke("baseCreate", myObject); } } 

Answer 3

You say you are using TDD — presumably there is some specification of the required behavior, either Derived , or Base , or both. Therefore, you will write some tests around this specification. Those tests will not require you to do Derived extend Base — they will simply require the specific behavior of each class; and this will be a behavior that can be implemented without using inheritance at all.

Once your tests pass, the next stage of the TDD will begin. This is the “refactoring” phase where you are looking for improvements in how your classes are developed. This is the moment when you decide to make Derived extend Base and call the create baseCreate method. The great thing is that when you do refactoring, you already have some tests to make sure that it worked correctly.