Java – org.mockito.exceptions.misusing.NotAMockException

In your entity class, when you declare mapping from user to roles, try specifying the fetchType to EAGER. Some thing like this:

@OneToMany(fetch=FetchType.EAGER)
public Collection<Role> getRoleSet(){
 ...
}

UPDATE: Recent comments this answer's received make me revisit this. It's been a while since I answered, when I only started working with Hibernate. What Rafael and Mukus say are reasonable. If you have a large collection, you shouldn't use eager fetching. It jointly selects all data mapped to your entry and loads to memory. An alternative to this is to still use lazy fetching and open a Hibernate session each time you need to work on the related collection, i.e, each time you need to invoke getRoleSet method. This way, Hibernate will execute the select query to database each time this method is invoked and doesn't keep the collection data in memory. You can refer to my post here for details: http://khuevu.github.io/2013/01/20/understand-hibernate.html

That's said, it can depend on your actual use case. If your collection data is small and you frequently need to query the data, you will better off using eager fetching. I think, in your specific case, a collection of role is probably quite small and suitable to use eager fetching.

There are a couple of things you could do to improve your code:

1. Switch to slf4j. This will allow you to code to an interface and be agnostic of the logging implementation under the covers (apache log4j in your case).

2. Switching to slf4j will allow you to not have to concatenate strings when passing to the logging framework - example:

   • this statement: LOGGER.debug("The list already has {} entries" + list.size());
   • can be written like this: LOGGER.debug("The list already has {} entries", list.size());

This has the added benefit of making the place holder in the string literal actually work.

3. You are attempting to assert and capture calls to an object indirectly via the the Logging framework. This will be fragile and error prone as you never know what calls will be made internally in the Logging framework. Mock only your direct dependencies.

4. Don't test logging statements. It's not exactly visible behavior of the class and it makes the test fragile and complicated. Plus, treating the logging statements as you would say using an ArrayList (i.e. part of the language) allows them to be fully exercised AND they output info to the console that may be helpful in debugging a failing test. An example of being fragile is, if you change the logging statement to add more info or maybe you add another logging statement to the method, this test could break for no good reason. At the very least don't assert the number of times called as this will be extremely fragile.

All of that said, if you must test the interactions with the Logging framework - here is a modified version of your code that runs and provides the same functionality. This is basically option #3 from the list of improvements -

package com.spring.mockito;

import static org.mockito.Mockito.spy;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

import org.apache.log4j.Logger;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.runners.MockitoJUnitRunner;

import java.util.Arrays;
import java.util.List;

@RunWith(MockitoJUnitRunner.class)
public class AppTest {

    // create a mock of the logger
    @Mock
    private Logger logger;

    private App uut;

    // Not needed - dont test something that gets called through something else
    // @Captor
    // private ArgumentCaptor<LoggingEvent> captorLoggingEvent;

    @Before
    public void setup() {
        // spy the class under test so we can override the logger method to return our mock logger
        uut = spy(new App());
        when(uut.logger()).thenReturn(logger);

        // Not needed test with the mock directly.
        // Logger root = Logger.getRootLogger();
        // root.addAppender(mockAppender);
        // root.setLevel(Level.DEBUG);
    }

    /**
     * I want to test with over 3 elements.
     */
    @Test
    public void testWithOver3Element() {
        List<String> myList = Arrays.asList("value 1", "value 2", "value 3", "value 4");

        List<String> outputList = uut.addToListIfSizeIsUnder3(myList, "some value");

        Assert.assertEquals(4, outputList.size());
        Assert.assertFalse(myList.contains("some value"));
        verify(logger, times(1)).debug("The list already has {} entries4");

        // not needed
        // try {
        // verify(mockAppender, times(1)).doAppend(captorLoggingEvent.capture());
        // } catch (AssertionError e) {
        // e.printStackTrace();
        // }
        //
        // LoggingEvent loggingEvent = captorLoggingEvent.getAllValues().get(0);
        // Assert.assertEquals("The list already has {} entries", loggingEvent.getMessage());
        // Assert.assertEquals(Level.DEBUG, loggingEvent.getLevel());
    }

    public static class App {
        private static final Logger LOGGER = Logger.getLogger(App.class);

        public List<String> addToListIfSizeIsUnder3(final List<String> list, final String value) {
            if (list == null) {
                logger().error("A null list was passed in");
                return null;
            }
            if (list.size() < 3) {
                list.add(value);
            } else {
                // if you use slf4j this concatenation is not needed
                logger().debug("The list already has {} entries" + list.size());
            }
            return list;
        }

        // make a package private method for testing purposes to allow you to inject a mock
        Logger logger() {
            return LOGGER;
        }
    }
}

You can also look at packages like PowerMockito for mocking statics - but only if absolutely needed.

Hope this helps.