Почему тесты Spock Speck настолько многословны?

Question

Исходя из фона JUnit Я не совсем понимаю смысл всего текста в тестах spockD, так как они не отображаются на выходе теста.

Так, например, если у меня есть ограничение на поле Double обув с ограничениями Foo макс: 5, обнуляемым: ложные

И я пишу тесты, как это:

void "test constraints" { 
    when: "foo set to > max" 
    foo=6D 
    then: "max validation fails" 
    !foo.validate() 
    when: "foo is null 
    foo=null 
    then: "null validation fails" 
    !foo.validate() 
} 

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

Все, что я получаю

Failure: | 
test constraints(com.grapevine.FooSpec) 
| 
Condition not satisfied: 
f.validate() 
| | 
| false  

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

По крайней мере, с помощью JUnit я мог сделать

foo=60D; 
assertFalse("contraints failed to block foo>max", f.validate()); 
foo=null; 
assertFalse("contraints failed to block foo=null", f.validate()); 

И тогда я хотел бы получить полезную информацию обратно из в отчете о неисправности. Что представляется более кратким и дает более информативный отчет об отказе от тестирования.

Есть ли какой-то способ получить более надежную отчетность об ошибках из Spec, которая использует все эти типизации, когда и затем оговорки, чтобы они отображались в отчетах об отказах, чтобы вы знали, что на самом деле не удается? Являются ли эти «когда» и «затем» текстовые дескрипторы, служащие только внутренней исходной документацией или они где-то используются?

Answer 1

Описание блоков в основном предназначено для испытаний более высокого уровня; они редко используются в модульных тестах. Тем не менее, есть несколько расширений отчетов третьих сторон Спока:

• https://github.com/damage-control/report
• https://github.com/renatoathaydes/spock-reports
• https://github.com/allure-framework/allure-spock-adaptor
• https://github.com/chanwit/spock-report-html

По крайней мере, некоторые из этих описаний выходных заблокируют, а также , Кроме того, планируется отправить расширенную отчетность «из коробки» со следующей версией Spock.

Вместо проверки одного из двух несвязанных случаев (как в вашем примере Spock/JUnit), как правило, лучше иметь отдельный тест с описательным именем для каждого случая. С этим могут помочь тесты, основанные на данных Spock.

Хотя можно добавить описание состояния Spock (например, assert 1 == 2, "not quite"), я почти всегда предпочитаю выход по умолчанию «power assert».

Чтобы ответить на ваш вопрос с заголовком, хорошо написанные тесты Спока, как правило, много меньше словесный, чем тесты JUnit.