How to use should_do_the_trick_of_instantiating method of org.mockito.internal.configuration.injection.ConstructorInjectionTest class

Yes. You've misused verify. The argument to verify has to be the mock itself. Then you call the method you want to verify on the value that's returned by verify. So in this case, the first verify call should be

Mockito.verify(_client).resource(_baseUrl + "token");

and similarly for the other verify calls.

For the future I would recommend Eran Harel's answer (refactoring moving new to factory that can be mocked). But if you don't want to change the original source code, use very handy and unique feature: spies. From the documentation:

You can create spies of real objects. When you use the spy then the real methods are called (unless a method was stubbed).

Real spies should be used carefully and occasionally, for example when dealing with legacy code.

In your case you should write:

TestedClass tc = spy(new TestedClass());
LoginContext lcMock = mock(LoginContext.class);
when(tc.login(anyString(), anyString())).thenReturn(lcMock);

You need to have prepared the class calling the constructor, not the class on which the constructor is called, the following should fix you up:

@PrepareForTest(DummyTarget.class)

For more information check this page.

Matchers.any(Class) will do the trick:

Mockito.when(object.doThings(Matchers.any(MyEnum.class), Matchers.anyLong()))
    .thenReturn(123L);

null will be excluded with Matchers.any(Class). If you want to include null you must use the more generic Matchers.any().

As a side note: consider using Mockito static imports:

import static org.mockito.Matchers.*;
import static org.mockito.Mockito.*;

Mocking gets a lot shorter:

when(object.doThings(any(MyEnum.class), anyLong())).thenReturn(123L);

Nutshell: Can't always use when to stub spies; use doReturn.

Assuming static imports of spy and doReturn (both PowerMockito):

@RunWith(PowerMockRunner.class)
@PrepareForTest(B.class)
public class BTest {
    @Test public void testClass() throws Exception {
        B b = spy(new B());
        doReturn(42).when(b, "m");
        b.asd();
    }
}

You could also @PrepareForTest(A.class) and set up the doReturn on when(a, "m"). Which makes more sense depends on the actual test.

As the error message suggests, you cannot mock final classes with the default Mockito.

But the community came up with mockito-inline, an extension bringing experimental features such as mocking final classes and methods or static methods.

Just add this in your pom.xml and use Mockito normally.

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <scope>test</scope>
</dependency>

Just use the org.joda.time.DateTimeUtils#setCurrentMillisFixed method of JodaTime which was designed to fix new DateTime() to a different time than the current time. To return to the normal time use org.joda.time.DateTimeUtils#setCurrentMillisSystem afterwards. No mocking needed.

@Test
public void test() {
DateTimeUtils.setCurrentMillisFixed(10L);
// .. your code
}

@After
public void cleanup() {
// Make sure to cleanup afterwards
DateTimeUtils.setCurrentMillisSystem()
}

Hate to be the person but: simply don't test this. Test the output, side effects, results - not the implementation.

If you really want to ensure the correct order, extract these methods into separate class(es) and mock them.

You can chain doReturn() method calls:

doReturn(true).doReturn(true).doReturn(false).when(rs).next();

Or, as mentioned in the comments, chain thenReturn method calls:

when(rs.next()).thenReturn(true).thenReturn(true).thenReturn(false);

Or, if you want to take things even further, you can use Mockito Answers:

when(rs.next()).thenAnswer(new Answer() {
    private int iterations = 2;

    Object answer(InvocationOnMock invocation) {
        return iterations-- > 0;
    }
});