Блог

При тестировании Spock when: строго необходимы then: метки блоков и (сами метки, а не код / фазы, которые они разделяют)? Или это технически просто синтаксический сахар, который можно опустить (при сохранении / сохранении строк кода, которые в противном случае были бы разделены метками)?

Я не уверен, что фазы стимула / ответа (соответствующие when / then) по-прежнему выполняются одинаково при пропуске меток?

(Мне любопытно спросить об этом, чтобы, возможно, сэкономить несколько строк кода; это может быть относительно тривиально, но я ценю, если кто-нибудь, кто может ответить, порадует меня. Я нахожусь в контексте, где нет нетехнических или менее технических пользователей, читающих или пишущих тесты Spock — я уважаю другие контексты, в которых включение меток улучшает читаемость для других не / менее технических пользователей; это имеет смысл.)

Например (1), рассмотрим приведенный ниже метод функции:

 def "a feature method with when/then labels"(){
  // setup phase code

  when:
  // stimulus phase code

  then:
  // response phase code

  where:
  // data table
}
 

Будет ли приведенное ниже (пример 2) редактирование (из приведенного выше примера, удаляющее только метки when / then) по-прежнему функционально эквивалентно приведенному выше?

 def "a feature method withOUT when/then labels"(){
  // setup phase code

  // stimulus phase code

  // response phase code

  where:
  // data table
}
 

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

Я не удивлюсь, если приведенный выше пример 2 представляет собой все, что находится над его where блоком, в его неявно заданном блоке. Но даже если это так, я не уверен, будет ли это иметь значение, поскольку два примера функционально эквивалентны или нет.

Вот несколько фактов о парах блоков when / then (для общего контекста для других):

• Если вы пишете одну из меток {when, then}, вы должны написать другую — они всегда существуют в [смежных] парах. Нельзя просто написать when: или просто then: (для данной пары фаз стимула / ответа)
• Несколько пар блоков when / then в одном и том же методе функций отлично подходят
• Функциональный метод всегда должен иметь как минимум 1 помеченный блок (для этого, я думаю, не имеет значения, какой именно)

Я предлагаю вам прочитать руководство Spock . Блоки несут семантику, и в зависимости от того, как вы их структурируете, компилятор Groovy применит преобразования AST (абстрактное синтаксическое дерево) к вашим спецификациям Spock.

Почему вы используете Spock и пытаетесь отбросить саму семантику, предоставляемую вам этим инструментом? Если вам не нравится поведенческая структура тестов Spock, просто используйте тесты pure Java или Groovy и инструмент по вашему выбору, такой как JUnit или TestNG. Но тогда, если вы хотите использовать mocks, вам понадобятся дополнительные инструменты-макеты, которые, по иронии судьбы, часто повторно вводят структуру, основанную на поведении, когда-тогда или с учетом ожидаемого типа структуры.

Как вы заметили, как минимум, вам нужен хотя бы один блок, специфичный для Spock, чтобы тест был идентифицирован как функциональный метод. Хотя вы могли бы опустить given|setup и просто использовать expect вместо when-then , это применимо только к случаям, в которых это имеет смысл. Постарайтесь не вводить все в эту структуру, а также использовать другие типы блоков, чтобы четко описать каждую функцию в вашей спецификации. Технически then|expect блок предоставляет вам семантику автоматических утверждений для всех заданных условий (без необходимости использования assert или подобного метода JUnit assertEquals ). where Блок обеспечивает простую параметризацию метода функции. Дополнительный cleanup блок помогает вам закрывать и / или очищать тестовые ресурсы без необходимости вручную использовать try-finally конструкции.

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