The Spring Cache Manager relies on Spring managing the application. You can't get that with the PowerMockRunner, you need to use SpringJUnit4Runner. You can still use PowerMock or Mockito programmatically, but not as a Runner.

Typically, you'll turn your unit test into a Spring-style integration test, something like this:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class SpringTest {

    @Configuration
    @EnableCaching
    static class SpringConfig{
        @Bean
        public CustomerService customerService(){
            return new CustomerServiceImpl(customerRepository());
        }
        @Bean
        public CustomerRepository customerRepository(){
            return Mockito.mock(CustomerRepository.class);
        }
    }

    @Autowired
    CustomerService customerService; // this will contain a proper managed cache

    @Autowired
    CustomerRepository customerRepository; // this is a mockito mock you can fine-tune
}

I am not aware of any way to go about this, for one clear reason: @InjectMocks is meant for non-mocked systems under test, and @Mock is meant for mocked collaborators, and Mockito is not designed for any class to fill both those roles in the same test.

Bear in mind that your @Mock(CALLS_REAL_METHODS) declaration is inherently dangerous: You're testing your AbstractClassUnderTest, but you are not running any constructors or initializing any fields. I don't think you can expect a test with this design to be realistic or robust, no matter what annotations can or cannot do for you. (Personally, I was previously in favor of real partial mocks of abstract classes as a "tool in the toolbox", but I'm coming around to thinking they're too far removed from reality to be useful.)

Were I in your position, I would create a small override implementation for testing:

@RunWith(JUnit4.class) public class AbstractClassTest {
  /** Minimial AbstractClass implementation for testing. */
  public static class SimpleConcreteClass extends AbstractClass {
    public SimpleConcreteClass() { super("foo", "bar", 42); }
    @Override public void abstractMethod1() {}
    @Override public String abstractMethod2(int parameter) { return ""; }
  }

  @InjectMocks SimpleConcreteClass classUnderTest;
  @Mock mockClassA;
  @Mock mockClassB;
}

At this point, you have a simple and predictable AbstractClass implementation, which you can use even without a mocking framework if you just wanted to test that AbstractClass has the same API for extension that it did before. (This is an often-overlooked test for abstract classes.) You can even extract this, as it may be useful for other testing: Should you want to override the abstract behavior for a single test class, you can create an anonymous inner class with just a single method override, or you can set classUnderTest = spy(classUnderTest); to set up Mockito proxying and the behavior you want.

(Bear in mind that @InjectMocks and @Spy can't be used reliably together, as documented in this GitHub issue and the Google Code and mailing list threads to which it links.)

The argThat return type is not being inferred for some reason. Try explicitly casting as shown below:

 Mockito.verify(foo).bar((Map<String, String>) argThat(Matchers.hasEntry("paramName", "paramValue")));

The testHasEntryCast() can be fixed as shown below. Notice that cast (Map<String, ?>) is to argThat return type:

@Test
public void testHasEntryCast() {
    Service mockService = mock(Service.class);
    Foo foo = new Foo(mockService);

    foo.bar();

    verify(mockService).activate((Map<String, ?>)  argThat(hasEntry("paramName", "paramValue")));
}

(This pretty much helped me figure it out)

Pretty simple solution (I almost had it right to begin with): I was missing a few PowerMockito dependency jars (from https://code.google.com/p/powermock/wiki/Downloads?tm=2): Specifically {cglib-nodep-2.2.2.jar, javssist-3.18.1-GA.jar, objenesis-2.1.jar}.

It was a simple solution and kinda dumb mistake to begin with in the 1st place, since that powerMock googleCode download page has all of them: At 1st, when I had the problem, I had only downloaded and added powermock-mockito-1.5.4-full.jar; I already had the JUnit & Mockito jars, so I think that set of 3 let me write PowerMock code without any compile errors in Eclipse. The googlecode download page has the powermockito jar + dependecies in a zip, but also said powerockito jar available alone too. That situation made it kinda hard to realize I was missing some others since it appeared I had all I need from that perspective (thought I already had the dependencies I needed per my existing JUnit and Mockito jars).

In actuality, the zip with dependencies had the additional ones I needed to solve the problem. I should have double-checked that 1st, but didn't realize I made the opposite bad assumption.

So... answer is to make sure to get the zip with all dependencies [and add them all to your buildpath]. Kinda obvious and dumb in my part in the end, but hey, a lot of software bugs and problems end up being that: Simple bad assumptions or overlooked details we don't realize we made, and therefore take a while to realize when troubleshooting...

If you are willing to use Spring test util, it's fairly easy with org.springframework.test.util.ReflectionTestUtils.

MappingDef mappingDef = Mappers.getMapper(MappingDef.class);
MappingUtils mappingUtils = Mappers.getMapper(MappingUtils.class);

...

// Somewhere appropriate
@Before
void before() {
    ReflectionTestUtils.setField(
        mappingDef,
        "mappingUtils",
        mappingUtils
    )
}

The following suggestion let's you test abstract classes without creating a "real" subclass - the Mock is the subclass.

use Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS), then mock any abstract methods that are invoked.

Example:

public abstract class My {
  public Result methodUnderTest() { ... }
  protected abstract void methodIDontCareAbout();
}

public class MyTest {
    @Test
    public void shouldFailOnNullIdentifiers() {
        My my = Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS);
        Assert.assertSomething(my.methodUnderTest());
    }
}

Note: The beauty of this solution is that you do not have to implement the abstract methods, as long as they are never invoked.

In my honest opinion, this is neater than using a spy, since a spy requires an instance, which means you have to create an instantiatable subclass of your abstract class.

Inner static class configuration: When testing Spring components we usually use @RunWith(SpringJUnit4ClassRunner.class) and make our class @ContextConfiguration. By making class @ContextConfiguration you can create an inner static class for configuration and in it you have full control. There you define all you need as beans and @Autowired it in your test, along with dependencies which can be mocks or regular objects, depending on test case.

Component scanning production code: If there are more components needed for test you can add @ComponentScan but we try to make it scan only packages it needs (this is when you use @Component annotation but in your case you can add XML to @ContextConfiguration). This is a good choice when you do not need mocks and you have a complicated setup which needs to be production like. This is good for integration tests where you want to test how components interact with each other in functional slices you want to test.

Hybrid approach: This is the usual case when you have many beans which need to be production like but one or two need to be mocks. Then you can @ComponentScan production code but add an inner static class which is @Configuration and there define beans with annotation @Primary which will override production code configuration for that bean in case of tests. This is good since you do not need to write long @Configuration with all defined beans, you scan what you need and override what should be mocked.

In your case I would go with first approach like this:

package org.world.hello;

import static org.junit.Assert.*;
import org.mockito.Mockito;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class RoomTest {

    @Configuration
    //@ImportResource(value = {"path/to/resource.xml"}) if you need to load additional xml configuration
    static class TestConfig {
       @Bean
       public BottleCounter bottleCounter() {
        return Mockito.mock(BottleCounter.class);
       }

       @Bean
       public Room room(BottleCounter bottleCounter) {
         Room room = new Room();
         room.setBottleCounter(bottleCounter);
         //r.setNumBottles(3); if you need 3 in each test
         return room;           
       }
    }

    @Autowired
    private Room room;  //room defined in configuration with mocked bottlecounter

    @Test
    public void testThreeBottlesAreSeperatedByNewLines()
    {
        Mockito.when(b.countBottle(Mockito.anyInt())).thenReturn("a");
        r.setNumBottles(3);
        assertEquals("a\na\na\na\n", r.generatePoem());
    }

}

Chris and Fildor are correct to try to mock the Logger.getLogger(). Unfortunately the way Log4J works makes that technically tricky.

Here's the code I came up with (tested) based on your sample above.

ClassUnderTest.java

import org.apache.log4j.Logger;

public class ClassUnderTest {
    private static Logger logger = Logger.getLogger(ClassUnderTest.class);

    public void run() {
        logger.info("Hello.");
    }
}

MockLog4JTest.java

import static org.mockito.Matchers.eq;
import static org.mockito.Mockito.verify;
import static org.powermock.api.mockito.PowerMockito.mock;

import org.apache.log4j.Logger;
import org.junit.BeforeClass;
import org.junit.Rule;
import org.junit.Test;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.rule.PowerMockRule;
import org.powermock.reflect.Whitebox;

@PrepareForTest(ClassUnderTest.class)
public class MockLog4JTest {
    @Rule
    public PowerMockRule rule = new PowerMockRule();

    @BeforeClass
    public static void oneTimeSetup() {
        System.setProperty("log4j.defaultInitOverride", Boolean.toString(true));
        System.setProperty("log4j.ignoreTCL", Boolean.toString(true));
    }

    @Test
    public void testLog()
    {
        ClassUnderTest classUnderTest = new ClassUnderTest();
        Logger mockLogger = mock(Logger.class);

        Whitebox.setInternalState(ClassUnderTest.class, "logger", mockLogger);

        classUnderTest.run();

        verify(mockLogger).info(eq("Hello."));
    }
}

I chose to go with using Whitebox to outright set the static field on the class under test to my mockLogger instance. After that, verification was pretty straightforward.

OK, I think this is very specific to TestNG configurations, since all of the JUnit examples work 'out of the box'!

Read through this link from the PowerMock GitHub site which describes further detail on how to use TestNG together with PowerMock. Exactly your scenario of verifying calls to mocked static methods is described there using this example code:

@PrepareForTest(IdGenerator.class)
public class MyTestClass {

   @Test
   public void demoStaticMethodMocking() throws Exception {
      mockStatic(IdGenerator.class);
      when(IdGenerator.generateNewId()).thenReturn(2L);       
      new ClassUnderTest().methodToTest();

      // Optionally verify that the static method was actually called
      verifyStatic();
      IdGenerator.generateNewId();
   }

}

Which is then followed by this nugget of information:

For this to work you need to tell TestNG to use the PowerMock object factory

This is done using either TestNG XML config, or in the test's code itself. For completeness I've copied below the options given at the above URL. FWIW I extended PowerMockTestCase and the verification worked as you expect.

Finally, don't forget to @PrepareForTest the correct class - i.e. the class containing the static methods which you want to mock, as @Bax pointed out here.

As a further hint (which you probably already know about, but worth mentioning here anyway) since you aren't using Mockito to mock objects, MockitoAnnotations.initMocks(this) can be safely deleted.

Once you've got all this working, you might also like to consider whether the use of 'Black Magic' tools like Powermock is actually exposing code smells in your design? Especially since it looks like the classes containing static methods are under your ownership. This means you could use an alternative design that doesn't use statics. I highly recommend Michael Feathers' book Working Effectively with Legacy Code, it might just change your whole approach to software design and testing...

Good luck!

Configure TestNG to use the PowerMock object factory

Using suite.xml

In your suite.xml add the following in the suite tag: object-factory="org.powermock.modules.testng.PowerMockObjectFactory" e.g.

<suite name="dgf" verbose="10"
    object-factory="org.powermock.modules.testng.PowerMockObjectFactory">
    <test name="dgf">
        <classes>
            <class name="com.mycompany.Test1"/>
            <class name="com.mycompany.Test2"/>
        </classes>
    </test> 

If you're using Maven you may need to point out the file to Surefire:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <suiteXmlFiles>
        <suiteXmlFile>suite.xml</suiteXmlFile>
        </suiteXmlFiles>
    </configuration> 
</plugin> 

Programmatically

Add a method like this to your test class:

@ObjectFactory public IObjectFactory getObjectFactory() {
     return new org.powermock.modules.testng.PowerMockObjectFactory(); 
} 

or to be on the safe side you can also extend from the PowerMockTestCase:

@PrepareForTest(IdGenerator.class) 
public class MyTestClass extends PowerMockTestCase { ... }