Почему mockito сообщает об ошибке на thenReturn() в java 7, но не в java 6

Mockito сообщает о незавершенной ошибке обрушения при издевательском client.getPrograms(), который должен возвращать SortedSet<Program>. Интересная часть заключается в том, что он делает это только при использовании Java 7, а не при использовании Java 6.

Здесь код, который вызывает ошибку при издевательском client.getPrograms():

private void prepareScheduleChangePreconditions() {
    Client client = mock(Client.class);
    TimeTable tt = BuilderUtil.buildTable(AcceleratedScheduleTimeTable.Schedule.NORMAL, "08:00");
    when(clientRepository.findByCode(anyString())).thenReturn(client);
    //Error is reported for next line of code
    when(client.getPrograms()).thenReturn(new TreeSet<Program>(Collections.singleton(program)));
    when(event.getTimeTable()).thenReturn(tt);      
}

Здесь вывод ошибки:

Tests in error:
  testExampleScheduleChangeNotify1(com.example.service.impl.ExampleServiceImplTest):
Unfinished stubbing detected here:
-> at com.example.service.impl.ExampleServiceImplTest.prepareScheduleChangePreconditions(ExampleServiceImplTest.java:134)

E.g. thenReturn() may be missing.
Examples of correct stubbing:
    when(mock.isOk()).thenReturn(true);
    when(mock.isOk()).thenThrow(exception);
    doThrow(exception).when(mock).someVoidMethod();
Hints:
 1. missing thenReturn()
 2. you are trying to stub a final method, you naughty developer!

Метод не является окончательным. Любая помощь или подсказки будут оценены.

ОБНОВЛЕНИЕ 1

В соответствии с запросом Mike B мне удалось выделить это в более простой тестовый пример, который не работает в Java 7.

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest {

    @Mock
    Program program;

    private void preparePreconditions() {
        Client client = mock(Client.class);
        when(client.getPrograms()).thenReturn(new TreeSet<Program>(Collections.singleton(program)));
    }

    public static class Client {
        public SortedSet<Program> getPrograms() {
            return new TreeSet<Program>();
        }
    }

    public static class Program implements Comparable<Program> {
        private String name;

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }

        @Override
        public int compareTo(Program program) {
            return 0;
        }
    }

    @Test
    public void test() {
        preparePreconditions();
    }

}

ОБНОВЛЕНИЕ 2

Как ни странно, он работает, если я так делаю:

TreeSet<Program> programs = new TreeSet<Program>();
programs.add(program);
when(client.getPrograms()).thenReturn(programs);

ОТВЕТЫ

Ответ 1

Я считаю, что то, что на самом деле происходит здесь, - это более одного вызова метода mock в одиночном выражении when(...).then(...).

Рассмотрим следующий пример:

when(program.getName()).thenReturn(String.valueOf(program.compareTo(null)));

Он возвращает то же исключение, что и у вас. Это связано с тем, что в mock используются два метода: getName() и compareTo() в одном выражении when(...).thenReturn(...).

Также в этой странице (документация mockito) Вы можете прочитать, что:

По умолчанию для всех методов, возвращающих значение, mock возвращает null, пустую коллекцию или соответствующее примитивное/примитивное значение обертки (например: 0, false,... для int/Integer, boolean/Boolean,...),

Поэтому mockito должен иметь некоторый механизм для обнаружения того, что делать (возврат), для которого вызов на каком-то издеваемом объекте.

В вашем примере второй вызов выполняется оператором new TreeSet<>(Collections.singleton(program)), потому что конструктор TreeSet использует метод compareTo() вашего макета.

Кажется, что реализация TreeSet изменилась с java 6 на java 7. Вот почему она могла работать раньше.

Ответ 2

Это на самом деле не отвечает на ваш вопрос, но помните о главной директиве насмешки:

  • Ролевые роли, а не объекты

На практике это означает, что высмеивание класса (т.е. не интерфейса) является мигающим красным предупреждающим знаком о том, что что-то не так с вашим дизайном.

Если у вас нет контроля над кодом, с которым вы взаимодействуете (например, это сторонняя библиотека или устаревшее программное обеспечение), мне нравится обернуть класс в интерфейс и издеваться над этим. В качестве бонуса это также позволяет вам переименовать неправильно названные методы (и классы) в другой код. Из вашего примера, какие "программы" возвращают клиент? Это набор активных программ, запущенных программ, что? Предположим, что это набор активных программ:

public interface Programs {
    SortedSet<Program> active();
}

class SimpleClientWrapper implements Programs {
    private final Client wrapped;

    SimpleClientWrapper(Client c) { wrapped = c; }

    public SortedSet<Program> active() { return wrapped.getPrograms(); }
}

Если это похоже на слишком много работы (и я признаю, что иногда это слишком много), другая возможность, если метод (ы), который вы хотите высмеять, не является окончательным, заключается в том, чтобы временно переопределить их в вашем тесте:

Client client = new Client() {
    @Override
    public SortedSet<Program> getPrograms() {
        return new TreeSet<Program>(Collections.singleton(program));
    }
};

Я иногда использую этот подход для переопределения обработчиков ошибок и т.д.