How to use shouldCheckIfVerificationWasFinished method of org.mockito.internal.progress.ThreadSafeMockingProgressTest class

You could do this by using an Answer to increment a counter if any of the methods are called.

private Answer incrementCounter = new Answer() {
    public Object answer(InvocationOnMock invocation) throws Throwable {
        counter++;
        return null;
    }        
};

Note that you need to stub all methods. A method's uniqueness is based on its signature and not just the method name. Two methods with the same name are still two different methods.

doAnswer(incrementCounter).when(mockObj.method1(anyString()));
doAnswer(incrementCounter).when(mockObj.method1(anyString(), anyString()));
doAnswer(incrementCounter).when(mockObj.method2(anyString()));

See documentation for doAnswer here.

No, there isn't. PostConstruct is a Spring concept. But nothing forbids you to call it in your setup method:

@Before
public void prepare() {
    MockitoAnnotations.initMocks(this);
    this.b.postConstruct();
}

Your test doesn't test any of your code. It tests that Mockito works fine.

When I introduce the concept of mocking, I take this example: suppose you build a detonator, and want to test it. You could of course use the detonator with a real bomb, and see if the whole block explodes when you use the detonator. But that isn't very practical. BTW, maybe you don't even have a bomb at your disposal. Maybe your colleague is still building it.

So you use a mock bomb. Note the important point: to test the detonator, you use a mock bomb. Not a mock detonator. What is mocked is the dependency of the class under test. Not the class under test itself.

What is a mock bomb? It's just a fake bomb that doesn't do anything. All it does is allowing to verify if has been asked to explode or not. So your code to test the detonator would be like this:

// create a mock bomb:
Bomb mockBomb = mock(Bomb.class);
// create a real detonator, but tie it to the mock bomb:
Detonator detonator = new Detonator(mockBomb);

// test the detonator. Since it's tied to a mock bomb, the block
// won't explode
detonator.pressTheRedButton();

// check it the mock bomb has been asked to explode, as it should 
// if the detonator works correctly
verify(mockBomb).explode();

Now if the test passes, you know that all the internal circuitry that is used in pressTheRedButton() works fine and eventually tells the bomb to explode. So you know that, when used with a real bomb, the real bomb will be asked to explode as well when pressing the red button.

Now let's come back to the real world: you want to test a service, and this service uses a DAO that needs a database, populated with data, to run fine. To test your service, you can simply mock the DAO, and verify it works fine. The mock DAO can also be used as a stub, i.e. an object that returns what you tell it to return in the test, instead of actually querying the database. That's what you're doing in the code in your question: you're telling the mock MyClass instance that, when add() is called with 2 and 2 as arguments, it should return 4.

This makes the test easier to setup, faster to run, and independant from the actual code of the DAO, which is not what you want to test in the unit test of the service.

You need to put the class where the constructor is called into the @PrepareForTest annotation instead of the class which is being constructed - see Mock construction of new objects.

In your case:

✗ @PrepareForTest(MyQueryClass.class)

✓ @PrepareForTest(A.class)

More general:

✗ @PrepareForTest(NewInstanceClass.class)

✓ @PrepareForTest(ClassThatCreatesTheNewInstance.class)

This is the expected behavior, when you mock something the created instance is a complete mock, so it makes no sense to initialize the fields as behavior is defaulted.

Aside of that, fields can be initialized by a constructor in concrete or abstract classes, as mocks instantiation bypasses the constructor simply because it's a mock, it is even more irrational to initialize them.

Trying to call the real method is usually wrong when using mocks. Instead one should stub the behavior of the mock.

Mockito.when(foo.isNull(Mockito.anyObject())).thenReturn(false);
Assert.assertFalse(foo.isNull("baaba")); // assertion always passing

I don't know your actual use case but maybe you want a partial mock, with a spy. Though that's still considered bad practice as it usually means you need to refactor the code to use composition.

To verify a static method using Mockito -> MockedStatic.

If the method has parameters and you want to verify it then it will be verify by this way:

@Test
void testMethod() {
  try (MockedStatic<StaticProperties> theMock = Mockito.mockStatic(StaticProperties.class)) {
    theMock.when(StaticProperties.getProperty("abc", "xyz", "lmn"))).thenReturn("OK");

    //code .....

    theMock.verify(() -> StaticProperties.getProperty("abc", "xyz", "lmn"));
  }
  
}

Use one, or more, ArgumentCaptors.

It is unclear what your types are here, but anyway. Let's suppose you have a mock which has a method doSomething() taking a Foo as an argument, then you do this:

final ArgumentCaptor<Foo> captor = ArgumentCaptor.forClass(Foo.class);

verify(mock).doSomething(captor.capture());

final Foo argument = captor.getValue();

// Test the argument

Also, it looks like your method returns void and you don't want it to do anything. Just write this:

doNothing().when(theMock).doSomething(any());

To answer your second question first. If you're using JUnit 4, you can annotate your test with

@Test(expected=MyException.class)

to assert that an exception has occured. And to "mock" an exception with mockito, use

when(myMock.doSomething()).thenThrow(new MyException());

You haven't mocked the behavior of getId in externalDependencyObject therefore it is returning null and giving you the NPE when toString() is called on that null.

You need a when(externalDependencyObject.getId()).then...