How to use OneConstructor method of org.mockito.internal.util.reflection.ParameterizedConstructorInstantiatorTest class

You have a servlet implementation that uses the ServletContext, e.g.

public class SomeServlet extends HttpServlet{

    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        ServletContext servletContext = getServletContext();
        Object attribute = servletContext.getAttribute("test");
        System.out.println(attribute.toString());
   }
}

in this case you have 2 options to test the doGet method

Use powermock's partitial mocking to only mock the getServletContext method.

@RunWith(PowerMockRunner.class)
public class SomeServletTest {

    @Test
    public void onGet() throws ServletException, IOException{
        SomeServlet someServlet = PowerMock.createPartialMock(SomeServlet.class, "getServletContext");   
        ServletContext servletContext = PowerMock.createNiceMock(ServletContext.class);
        HttpServletRequest httpServletRequest = PowerMock.createNiceMock(HttpServletRequest.class);
        HttpServletResponse httpServletResponse = PowerMock.createNiceMock(HttpServletResponse.class);

        someServlet.getServletContext();
        PowerMock.expectLastCall().andReturn(servletContext);

        servletContext.getAttribute("test");
        PowerMock.expectLastCall().andReturn("hello");

        PowerMock.replay(someServlet, servletContext, httpServletRequest, httpServletResponse);

        someServlet.doGet(httpServletRequest, httpServletResponse);
    }
}

or a simpler way is to just override the getServletContext method. In this case you don't need powermock. You can just do it using easymock. e.g.

public class SomeServletTest {

    @Test
    public void onGet() throws ServletException, IOException{
        HttpServletRequest httpServletRequest = EasyMock.createNiceMock(HttpServletRequest.class);
        HttpServletResponse httpServletResponse = EasyMock.createNiceMock(HttpServletResponse.class);
        final ServletContext servletContext = EasyMock.createNiceMock(ServletContext.class);
        SomeServlet someServlet = new SomeServlet(){
            public ServletContext getServletContext() {
                return servletContext; // return the mock
            }
        };

        EasyMock.expect(servletContext.getAttribute("test")).andReturn("hello");
        EasyMock.replay(servletContext, httpServletRequest, httpServletResponse);

        someServlet.doGet(httpServletRequest, httpServletResponse);
    }
}

there can be 100's. like initialContext.lookup() also dependent on container.

In this case you can either create an InitialContext mock and use this. If your code creates a new InitialContext, e.g.

public void someMethod(){
    InitialContext context = new InitialContext();
    context.lookup(....);
}

you can simply extract the InitialContext instantiation to a protected method that you can override in your tests like I showed above with the ServletContext

public void someMethod(){
    InitialContext context = createInitialContext();
    context.lookup(....);
}

protected InitialContext createInitialContext(){
    return new InitialContext(); // can be overridden by a subclass 
                                 // and therefore by tests as well to
                                 // return a mock
}

If you don't want or you can't modify the code in this way, then you can use Powermock to intercept the constructor.

EDIT

Can you post your Mockito code? It would be a pleasure, since the methods are named differently.

@Test
public void onGet() throws ServletException, IOException {
  HttpServletRequest httpServletRequest = Mockito.mock(HttpServletRequest.class);
  HttpServletResponse httpServletResponse = Mockito.mock(HttpServletResponse.class);
  final ServletContext servletContext = Mockito.mock(ServletContext.class);
  SomeServlet someServlet = new SomeServlet(){
    public ServletContext getServletContext() {
      return servletContext; // return the mock
    }
  };

  Mockito.doReturn("hello").when(servletContext).getAttribute("test");

  someServlet.doGet(httpServletRequest, httpServletResponse);
}

Mockito.verify(foo, Mockito.times(1)).add("1");
Mockito.verify(foo, Mockito.times(1)).add(Mockito.anyString());

The first verify checks the expected parametrized call and the second verify checks that there was only one call to add at all.

I think

Mockito.reset(wareHouseSpy)

would do it.

At my work we have recently put together a couple of test suites to test some RESTful APIs we built. Like your services, ours can invoke other RESTful APIs they depend on. We split it into two suites.

• Suite 1 - Testing each service in isolation
  • Mocks any peer services the API depends on using restito. Other alternatives include rest-driver, wiremock, pre-canned and betamax.
  • The tests, the service we are testing and the mocks all run in a single JVM
  • Launches the service we are testing in Jetty

I would definitely recommend doing this. It has worked really well for us. The main advantages are:

• Peer services are mocked, so you needn't perform any complicated data setup. Before each test you simply use restito to define how you want peer services to behave, just like you would with classes in unit tests with Mockito.
• The suite is super fast as mocked services serve pre-canned in-memory responses. So we can get good coverage without the suite taking an age to run.
• The suite is reliable and repeatable as its isolated in it's own JVM, so no need to worry about other suites/people mucking about with an shared environment at the same time the suite is running and causing tests to fail.

• Suite 2 - Full End to End
  • Suite runs against a full environment deployed across several machines
  • API deployed on Tomcat in environment
  • Peer services are real 'as live' full deployments

This suite requires us to do data set up in peer services which means tests generally take more time to write. As much as possible we use REST clients to do data set up in peer services.

Tests in this suite usually take longer to write, so we put most of our coverage in Suite 1. That being said there is still clear value in this suite as our mocks in Suite 1 may not be behaving quite like the real services.

With regards to your points, here is what we do:

• Ability to define integration test cases which exercise business scenarios.
  • We use cucumber-jvm to define business scenarios for both of the above suites. These scenarios are English plain text files that business users can understand and also drive the tests.
• Set up the DB with test data before suite is run.
  • We don't do this for our integration suites, but in the past I have used unitils with dbunit for unit tests and it worked pretty well.
• Invoke the REST API that is running on a remote server (Tomcat)
  • We use rest-assured, which is a great HTTP client geared specifically for testing REST APIs.
• Validate the DB post test execution for verifying expected output
  • I can't provide any recommendations here as we don't use any libraries to help make this easier, we just do it manually. Let me know if you find anything.
• Have code coverage report of REST API so that we know how confident we should be in the scenarios covered by the suite.
  • We do not measure code coverage for our integration tests, only for our unit tests, so again I can't provide any recommendations here.

Keep your eyes peeled on our techblog as there may be more details on their in the future.

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.

If you want the mocked method to call a method on (or otherwise alter) a parameter, you'll need to write an Answer as in this question ("How to mock a void return method affecting an object").

From Kevin Welker's answer there:

doAnswer(new Answer() {
    Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
        return null; // void method, so return null
    }
}).when(mock).someMethod();

Note that newer best-practices would have a type parameter for Answer, as in Answer<Void>, and that Java 8's lambdas can compress the syntax further. For example:

doAnswer(invocation -> {
  Object[] args = invocation.getArguments();
  ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
  return null; // void method in a block-style lambda, so return null
}).when(mock).someMethod();

One way is using reflection get rid of final modifier from the field and then replace the LOGGER field with Mocked one

public class Class1Test {
    @Test
    public void test() throws Exception {
        Logger logger = Mockito.mock(Logger.class);
        Mockito.when(logger.isInfoEnabled()).thenReturn(false);
        setFinalStatic(Class1.class.getDeclaredField("LOGGER"), logger);
        Class1 cls1 = new Class1();
        assertFalse(cls1.demoMethod());
    }

    static void setFinalStatic(Field field, Object newValue) throws Exception {
        field.setAccessible(true);        
        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
        field.set(null, newValue);
    }
}

TL;DR; Unfortunately, there is no built-in solution yet (at time of writting, 2022), hence you are free to use and/or implement whatever fits your situation.

Example

An alternative is to use the CountDownLatch class.

public class DatabaseTest {

    /**
     * Data limit
     */
    private static final int DATA_LIMIT = 5;

    /**
     * Countdown latch
     */
    private CountDownLatch lock = new CountDownLatch(1);

    /**
     * Received data
     */
    private List<Data> receiveddata;

    @Test
    public void testDataRetrieval() throws Exception {
        Database db = new MockDatabaseImpl();
        db.getData(DATA_LIMIT, new DataCallback() {
            @Override
            public void onSuccess(List<Data> data) {
                receiveddata = data;
                lock.countDown();
            }
        });

        lock.await(2000, TimeUnit.MILLISECONDS);

        assertNotNull(receiveddata);
        assertEquals(DATA_LIMIT, receiveddata.size());
    }
}

NOTE you can't just used syncronized with a regular object as a lock, as fast callbacks can release the lock before the lock's wait method is called. See this blog post by Joe Walnes.

EDIT Removed syncronized blocks around CountDownLatch thanks to comments from @jtahlborn and @Ring

You could extract a method for doing the actual reading and then test that instead. That would mean you only have to mock a single reader. For example, your code would be something like this:

public void aMethod(){
    File f = map.get("key1")
    BuffereReader r = new BufferedReader(new FileReader(f));
    readStuff(r);
}

public void readStuff(BufferedReader r){
    String line=null;
    do {
        line=r.readLine();
    } while(r!=null);
}

then your test code would be more like the following:

BufferedReader bufferedReader = Mockito.mock(BufferedReader.class);
Mockito.when(bufferedReader.readLine()).thenReturn("line1", "line2", "line3");
objUnderTest.readStuff(bufferedReader);
//verify result