Спок проверка вызова метода недавно созданного экземпляра - PullRequest
Новая
       83

Спок проверка вызова метода недавно созданного экземпляра

0 голосов
/ 12 апреля 2020

Я пытаюсь проверить, вызваны ли некоторые методы для вновь созданного экземпляра.

Я следовал руководству Спока по макету конструктора, но там написано слишком мало вызовов. 

Too few invocations for:

3 * mockStep.addTarget(_)   (0 invocations)

Unmatched invocations (ordered by similarity):

None

Вставка моего кода здесь ... 

public class Workflow {
    public void createStep() {
        Step step = new Step();
        step.addTarget("A");
        step.addTarget("B");
        step.addTarget("C");
    }
}

class WorkflowTest extends Specification {
    Workflow workflow

    def setup() {
        workflow = new Workflow()
    }

    def "each new step should have 3 targets" () {
        given:
        def mockStep = Mock(Step)
        GroovySpy(Step, global: true)
        new Step() >> mockStep

        when:
        workflow.createStep()

        then:
        3 * mockStep.addTarget(_)
    }
}

В Приведенный выше код Я пытаюсь разрешить всем новым Step () возвращать смоделированный Step и проверить, что mockStep.addTarget () вызывается 3 раза. Когда я работал в режиме отладки, кажется, что Step step = new Step(); по-прежнему возвращает новый экземпляр вместо смоделированного шага.

Ответы [ 2 ]

1 голос
/ 12 апреля 2020

Не используйте грязные трюки, такие как глобальные Groovy mocks, но вместо этого используйте рефакторинг для развязки, внедрения зависимостей и, как результат, лучшей тестируемости. Пожалуйста, прочитайте разделы "Общие комментарии" и "Еще несколько замечаний" моего ответа здесь , чтобы узнать причину, по которой вам следует провести рефакторинг. Я не хочу повторять здесь все.

Что касается технической причины, по которой ваш глобальный Groovy макет не работает из Java кода, я цитирую Руководство Спока :

Когда Groovy mocks следует отдавать предпочтение перед обычными mock?

Groovy mock следует использовать, когда специфицированный код записан в Groovy и некоторые из уникальных макетов Groovy необходимы. При вызове из кода Java макеты Groovy будут вести себя как обычные макеты. Обратите внимание, что нет необходимости использовать макет Groovy только потому, что код по спецификации и / или поддельный тип записывается в Groovy. Если у вас нет конкретной причины использовать макет Groovy, предпочтите обычный макет.

Обновление:

Самый быстрый способ рефакторинга это отделить создание шага от добавления целей. На самом деле имя createStep подразумевает, что метод делает именно это. Но вместо этого это также добавляет цели. Используйте два метода для этого и метод, выполняющий рабочий процесс. Затем вы можете использовать Spy для заглушки createStep (который возвращает созданный экземпляр Step) и затем проверять взаимодействия, если вы действительно думаете, что это вообще нужно проверить. Проверка внутренних взаимодействий часто является запахом кода (чрезмерная спецификация).

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

Если вы не понимаете, что я имею в виду под двумя альтернативами, пожалуйста, дайте мне знать.

0 голосов
/ 13 апреля 2020

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

Пожалуйста, обратитесь к официальной документации

...