Не используйте грязные трюки, такие как глобальные Groovy mocks, но вместо этого используйте рефакторинг для развязки, внедрения зависимостей и, как результат, лучшей тестируемости. Пожалуйста, прочитайте разделы "Общие комментарии" и "Еще несколько замечаний" моего ответа здесь , чтобы узнать причину, по которой вам следует провести рефакторинг. Я не хочу повторять здесь все.
Что касается технической причины, по которой ваш глобальный Groovy макет не работает из Java кода, я цитирую Руководство Спока :
Когда Groovy mocks следует отдавать предпочтение перед обычными mock?
Groovy mock следует использовать, когда специфицированный код записан в Groovy и некоторые из уникальных макетов Groovy необходимы. При вызове из кода Java макеты Groovy будут вести себя как обычные макеты. Обратите внимание, что нет необходимости использовать макет Groovy только потому, что код по спецификации и / или поддельный тип записывается в Groovy. Если у вас нет конкретной причины использовать макет Groovy, предпочтите обычный макет.
Обновление:
Самый быстрый способ рефакторинга это отделить создание шага от добавления целей. На самом деле имя createStep
подразумевает, что метод делает именно это. Но вместо этого это также добавляет цели. Используйте два метода для этого и метод, выполняющий рабочий процесс. Затем вы можете использовать Spy
для заглушки createStep
(который возвращает созданный экземпляр Step
) и затем проверять взаимодействия, если вы действительно думаете, что это вообще нужно проверить. Проверка внутренних взаимодействий часто является запахом кода (чрезмерная спецификация).
В качестве альтернативы добавьте фабричный класс для шагов и внедрите экземпляр в класс рабочего процесса. Тогда вы можете легко смоделировать фабричный класс и заставить его вернуть ложный шаг.
Если вы не понимаете, что я имею в виду под двумя альтернативами, пожалуйста, дайте мне знать.