JMockit и несколько локальных методов

Question

Допустим, у меня есть класс MyClass с методами x(), y() и z().Скажем, x() звонки y() и y() звонки z().

Так что каждый раз, когда я проверяю x(), вызываются и y(), и z().В случае подделки зависимостей MyClass мне придется смоделировать поведение зависимостей внутри x(), y() и z().

Так что, если мои тесты для метода x() равны testXWhen1(), testXWhen2() и testXWhen3() Мне придется повторить ожидания для моих зависимостей в каждом из методов тестирования.В конце у меня есть некоторый код с ожиданиями того, что происходит внутри y() и z(), повторенный для моих трех методов тестирования.Любое решение, чтобы избежать этого?

Одна из моих идей состояла в том, чтобы попытаться проверить действительный метод x(), но насмехаться над y() и z().В этом случае мой экземпляр MyClass должен быть частично ложным, а частично реальным MyClass.Возможно ли это?

Другое решение заключалось в том, чтобы строго соблюдать ожидания в x(), а не в том, что происходит в y() и z() ... Я думаю, что я могу сделать это с помощью @NonStrict@Mocked, но это не мое любимое решение.

Answer 1

Если вы хотите протестировать метод x(), тогда вам следует смоделировать метод y(). В этом случае вам не нужно также имитировать z(), потому что вы никогда не достигнете вызова z() внутри y().

Answer 2

Вы можете использовать функцию JMockit динамическое частичное моделирование , передав класс или объект для частичного моделирования в конструкторе Expectations/NonStrictExpectations.

В целом, однако, лучше избегать использования частичного макета, поскольку это часто указывает на отсутствие согласованности в тестируемом коде и приводит к тестам, которые труднее понять.

В тех случаях, когда в нескольких тестах требуется множество одинаковых ожиданий, всегда есть возможность создания многократно используемых блоков ожидания. Вы можете инкапсулировать ряд ожиданий в именованном подклассе «XyzExpectations», необязательно с параметризованными конструкторами, и создать его экземпляр в любом количестве тестов (фактически созданный экземпляр подкласса «ожиданий» должен быть final). То же самое можно сделать с проверочными блоками.

Answer 3

В конце у меня есть некоторый код с ожиданиями того, что происходит внутри y () и z (), повторенный для моих трех методов тестирования. Любое решение, чтобы избежать этого?

Вы пробовали рефакторинг «Метод извлечения»?

Другим решением было строго придерживаться ожиданий в x (), а не в отношении того, что происходит в y () и z () ...

Это именно то, что я делаю при тестировании определенной функциональности (хотя и с использованием JMock) - если поведение, которое я тестирую, не зависит от результата вызовов зависимостей, я буду явно использовать JMock, игнорируя / допуская ожидания. Это делает цель теста намного более ясной и сфокусированной на том, что именно тестируется.