How to use unfinished_stubbing_cleans_up_the_state method of org.mockitousage.stubbing.StubbingWithThrowablesTest class

When involving Spring:

If you want to use Spring test framework features in your tests like for example @MockBean, then you have to use @ExtendWith(SpringExtension.class). It replaces the deprecated JUnit4 @RunWith(SpringJUnit4ClassRunner.class)

When NOT involving Spring:

If you just want to involve Mockito and don't have to involve Spring, for example, when you just want to use the @Mock / @InjectMocks annotations, then you want to use @ExtendWith(MockitoExtension.class), as it doesn't load in a bunch of unneeded Spring stuff. It replaces the deprecated JUnit4 @RunWith(MockitoJUnitRunner.class).

To answer your question:

Yes you can just use @ExtendWith(SpringExtension.class), but if you're not involving Spring test framework features in your tests, then you probably want to just use @ExtendWith(MockitoExtension.class).

(I assume you can use Mockito though) Nothing dedicated comes to my mind but I tend to use the following strategy when it comes to situations like that:

1) In the class under test, replace the static direct call with a call to a package level method that wraps the static call itself:

public class ToBeTested{

    public void myMethodToTest(){
         ...
         String s = makeStaticWrappedCall();
         ...
    }

    String makeStaticWrappedCall(){
        return Util.staticMethodCall();
    }
}

2) Spy the class under test while testing and mock the wrapped package level method:

public class ToBeTestedTest{

    @Spy
    ToBeTested tbTestedSpy = new ToBeTested();

    @Before
    public void init(){
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void myMethodToTestTest() throws Exception{
       // Arrange
       doReturn("Expected String").when(tbTestedSpy).makeStaticWrappedCall();

       // Act
       tbTestedSpy.myMethodToTest();
    }
}

Here is an article I wrote on spying that includes similar case, if you need more insight: sourceartists.com/mockito-spying

Try @RunWith(PowerMockRunner.class) instead of @RunWith(MockitoJUnitRunner.class)

Mockito cannot mock final classes or methods. Try removing the final modifier from the hasInventory method. Or better yet, do not mock the Warehouse class, instead mock the IWarehouse interface, whose methods cannot be final, and presumably defines those used by Order.

In general, it's preferable to mock interfaces, but it's not mandatory.

Not being able to mock final classes or methods is briefly mentioned in the Mockito FAQ, it is due to the runtime class generation technique used for creating the mocks.

What you are asking is not possible because your legacy code relies on a static method getInstance() and Mockito does not allow to mock static methods, so the following line won't work

when(FormatterService.getInstance()).thenReturn(formatter);

There are 2 ways around this problem:

1. Use a different mocking tool, such as PowerMock, that allows to mock static methods.

2. Refactor your code, so that you don't rely on the static method. The least invasive way I can think of to achieve this is by adding a constructor to DriverSnapshotHandler that injects a FormatterService dependency. This constructor will be only used in tests and you production code will continue to use the real singleton instance.

   public static class DriverSnapshotHandler {
   
       private final FormatterService formatter;
   
       //used in production code
       public DriverSnapshotHandler() {
           this(FormatterService.getInstance());
       }
   
       //used for tests
       DriverSnapshotHandler(FormatterService formatter) {
           this.formatter = formatter;
       }
   
       public String getImageURL() {
           return formatter.formatTachoIcon();
       }
   }
   

Then, your test should look like this :

FormatterService formatter = mock(FormatterService.class);
when(formatter.formatTachoIcon()).thenReturn("MockedURL");
DriverSnapshotHandler handler = new DriverSnapshotHandler(formatter);
handler.getImageURL();
verify(formatter, atLeastOnce()).formatTachoIcon();

When you are invoking

Mockito.when(spy.isCertainValue()).thenReturn(true);

the method isCertainValue() is getting called here. This is how Java works: to evaluate the argument of Mockito.when, the result of spy.isCertainValue() must be evaluated so the method must be called.

If you don't want that to happen, you can use the following construct:

Mockito.doReturn(true).when(spy).isCertainValue();

This will have the same mocking effect but the method won't be called with this.

Mockito cannot mock static method. Your when check is not valid:

  when(BasketHelper.getAction(request)).thenReturn(0);
  when(BasketHelper.getActionProduct(site, request)).thenReturn(product);

That is another reason why we want to reduce the use of static method as it is hard to mock.

There is no easier way to mock the behavior if your class stays like this. However if you want to change your design and make both methods non-static. The correct way of using "when" is to apply the check on mocked object. For example:

  BasketHelper basketHelper = mock(BasketHelper.class);
  when(basketHelper.getAction(request)).thenReturn(0);
  when(basketHelper.getActionProduct(site, request)).thenReturn(product);

But once again, this only work if you re-designed your class's getAction and getProduct method to be NON-STATIC.

I remember there are some other testing framework that does support mocking static method.

I had the same error but for me it was caused by the fact that I had ommited the ID as URL parameter. I ommited it because the ID was present in the JSON body.

When I changed .../restaurant to ...restaurant/1, the error went away.

Wiremock provides a simulator for HTTP-based APIs while Mockito provides the mock implementation of the method/object.

If we are using Mockito to mock HTTP-based method, it means we are trying to return the object/response without testing any code to invoke REST service, getting HTTP response and deserializing the same.

If we use the Wiremock, we will able to test close to reality as it will test invocation of REST call as well as deserialization of the response.

https://www.linkedin.com/pulse/what-difference-between-stub-mock-virtual-service-wojciech-bulaty/ is one good article to read, of course not by me :-)