How to use assertNotClosed method of org.mockito.internal.MockedConstructionImpl class

PowerMockRunner is part of powermock-module-junit4.jar. You need to explicity import this jar

You could specify the dependency for this jar as per your requirement. Refer to this link.

Reopening as requested, but the solution (use an ArgumentMatcher) is identical to the one in the linked answer. Naturally, you can't use an ArgumentCaptor when stubbing, but everything else is the same.

class OfficeWithId implements ArgumentMatcher<Office> {
  long id;

  OfficeWithId(long id) {
    this.id = id;
  }

  @Override public boolean matches(Office office) {
    return office.id == id;
  }

  @Override public String toString() {
    return "[Office with id " + id + "]";
  }
}

when(client.callApi(anyString(), argThat(new IsOfficeWithId(123L)))
    .thenReturn(responseOne);

Because ArgumentMatcher has a single method, you can even make it a lambda in Java 8:

when(client.callApi(anyString(), argThat(office -> office.id == 123L))
    .thenReturn(responseOne);

If you're already using Hamcrest, you can adapt a Hamcrest matcher using MockitoHamcrest.argThat, or use the built-in hasProperty:

when(client.callApi(
  anyString(),
  MockitoHamcrest.argThat(
    hasProperty("id", equalTo(123L)))))
  .thenReturn(responseOne);

First of all, you should always mock the direct dependencies of an object, and not its transitive dependencies. So you should mock B, and not C, to test A. Then you would write a unit test for B by mocking C.

Second: you're not injecting the mock anywhere in the unit test. What you should have is:

public class Test {

    // not autowired here
    private A a;

    private B mockB;

    @Test
    public void testA() {
        mockB = mock(B.class);
        when(b.bFn(), anyInt()).thenReturn(something);

        // the missing part: injecting the mock into the tested object
        a = new A(mockB);
        // or a = new A();
        //    a.setB(mockB);

        assertEquals(0, a.aFn());
    }
}

When you use mock(B.class), you get one mock instance of B. That doesn't mean that all the other instances of B will do what the mock does.

Mocking C to test A is a bad practice: unit tests should test one class in isolation of the others. But if you really want that, then create a mock C, create a B and inject the mock C inside it, then create an A and inject the B inside it.

A --> B --> mockC

You need to define the behavior for getPath() for folder as it gets called internally in File class.

You can do it as:

File folder = Mockito.mock(File.class);
when(folder.getPath()).thenReturn("C:\temp\");
File file = new Agent().createNewFile(folder, "fileName");

It will work only till you don't really create a new file but only calling new File.

When you're using MockK you should not use Mockito.

Only using MockK you can achieve the same with:

val dal = mockk<UserDal> {
    every { insert(any()) } returnsArgument 0
}

If you intend to use Mockito, you should remove MockK and use mockito-kotlin:

val dal = mock<UserDal> {
    on { insert(any()) } doAnswer { it.arguments[0] }
}

Why do you need spring to do unit testing? You can only use Mockito to do so without the need to start spring context. This is explained and discussed in details here: https://reflectoring.io/unit-testing-spring-boot/

It's also very confusing for me when it comes to using @MockBean! Is that considered a unit or an integration test? In my opinion, even we're using a mocked bean, but we're still running within spring context and for me this is an integration test (as a unit test doesn't need any spring context to run within). Same site that Brandon mentioned considers @MockBean an integration test https://www.baeldung.com/java-spring-mockito-mock-mockbean.

Image from above site

From Brandon response: "Integration tests should not contain any mocking and both types of testing should be run separately."

What if you want to test an api starting from the controller all the way to DB, but you want to exclude other systems (like kafka or external Microservices)? How would you achieve this? You definitely need @MockBean. This is an integration test even it has mocked beans.

In summary (based on my experience and after searching and reading a lot of contradicting info for days). Here is my opinion:

• I would say, stay away from using spring for unit testing as much as possible and just use Mockito or another framework that doesn’t need spring context. For example, when writing a test for a service class to test some calculation logic, we don’t need spring context and this is a PURE unit test.
• We still can write PURE unit tests for controller classes. We can do that by calling the methods in the controller, then assert that these methods did what is expected (e.g. calling the right underlying methods with correct parameters ..etc). Basically the same way when writing a unit test for a service class. (Maybe these aren’t needed if it’s already gonna be covered in the following types of tests?)
• We still can write pure unit tests for apis without any spring context. This described here. I tried and it worked for me. I'll paste the code at the end of the post.
• When running a test in spring context, this is considered an integration test even if you're using @MockBean. An example of this: if we want to test an api starting from the controller all the way to the DB, but we want to exclude other systems (like kafka, email, or other external Microservices). How would we achieve this? We definitely need @MockBean. This is an integration test even though it uses some mocked beans.

• I think the most confusing part is when testing the api layer only using spring as UserControllerTest in the question does (I mean by that calling the api and making sure it returns the right status code and response format). Is that considered a unit test or an integration test? It is not a unit as unit tests don’t need spring context to run within. It is actually something in between unit and integration tests. This source explains this concept very well https://blog.marcnuri.com/mockmvc-spring-mvc-framework/ (more specifically MockMvc standalone setup) So I think, it goes back then to the team where to place these tests (in the unit test folder, in the integration test folder, in a separate folder?) Also a good naming convention is needed to be used to avoid any confusion with pure unit tests or pure integration tests for the same class. From what I saw, most teams consider those unit tests, but I am not sure if that is the best practice!

  //unit test to call an api using MockMvc and mockito only
  @RunWith(MockitoJUnitRunner.class)
  public class UserControllerTest {
  
  private MockMvc mockMvc;
  @Mock
  UserService userService;
  @InjectMocks
  UserController controllerUnderTest;
  
  @Before
  public void setup() {
      MockitoAnnotations.initMocks(this);
      mockMvc = MockMvcBuilders.standaloneSetup(controllerUnderTest).build();
  }
  
  @Test
  public void testGetUser() throws Exception {
  
      //given:
      when(userService.getUser(.......)).thenReturn(....);
  
      //when:
      String url = "http://localhost:8081/api/ ....your url";
  
      //then:
      this.mockMvc.perform(get(url)).andDo(print()).andExpect(status().isOk());
  }
  

  }

Hope that helps and please let me know if there is any better opinion because I struggled a lot with that :)

According to the Mockito documentation, you can make a mock serializable:

List serializableMock = mock(List.class, withSettings().serializable());

I think it should be

verify(mockBar, times(2)).doSomething(...)

Sample from mockito javadoc:

ArgumentCaptor<Person> peopleCaptor = ArgumentCaptor.forClass(Person.class);
verify(mock, times(2)).doSomething(peopleCaptor.capture());

List<Person> capturedPeople = peopleCaptor.getAllValues();
assertEquals("John", capturedPeople.get(0).getName());
assertEquals("Jane", capturedPeople.get(1).getName());

You are correct that is not a design issue on your part. Without PowerMock, your options become a bit murkier, though.

I would suggest creating a non-static wrapper for the FrameworkUtil class that you can inject and mock.

Update: (David Wallace)

So you add a new class to your application, something like this

public class UtilWrapper {
    public Bundle getBundle(Class<?> theClass) {
        return FrameworkUtil.getBundle(theClass);
    }
}

This class is so simple that you don't need to unit test it. As a general principle, you should only EVER write unit tests for methods that have some kind of logic to them - branching, looping or exception handling. One-liners should NOT be unit tested.

Now, within your application code, add a field of type UtilWrapper, and a setter for it, to every class that currently calls FrameworkUtil.getBundle. Add this line to the construtor of each such class

utilWrapper = new UtilWrapper();

And replace every call to FrameworkUtil.getBundle with utilWrapper.getBundle.

Now in your test, you make a mock UtilWrapper and stub it to return whatever Bundle you like.

when(mockUtilWrapper.getBundle(ConfigService.class)).thenReturn(someBundleYouMade);

and for the class that you're testing, call setUtilWrapper(mockUtilWrapper) or whatever. You don't need this last step if you're using @InjectMocks.

Now your test should all hang together, but using your mocked UtilWrapper instead of the one that relies on FrameworkUtil.