Один тест – одна проверка, а у вас сколько?

[dzhariy (Дмитрий Жарий)]

 

Возможность такого рода переиспользования GWT в Cucumber – я считаю грязным хаком.

Почему хаком? – потому что есть файл .feature, который содержит тест фичи и это специальное место для того чтобы вот так обычным текстом писать And Click on the "Reports" link

Есть файл step definition – там должен быть код, без «хрупкого» текста. Я уверен в том, что код нельзя мешать с обычным текстом.

Почему грязный? – потому что в тексте Given\When\Then есть всегда неоднозначность.

Вот например, читая строку:

And 'Click on the "Reports" link'

 

Я могу подумать, что "Reports" – может быть параметром для какого-нибудь шага. А, на самом деле, это может быть не так. По тексту я не могу определить, как будет работать шаг, и какие параметры он принимает, и мне придется лишний раз идти в код нужного мне шага, чтобы выяснить это.

 

С другой стороны,  этот код можно переписать без неоднозначностей:

 

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }When "I open reports tab" do

            LandingPage.visit()

            LandingPage.open_tab("Reports")

end{/syntaxhighlighter}

(Я Руби не очень хорошо знаю, так что назовем это
псевдокодом

 

А что за ограничения Specflow? Я признаю, что они есть. Вот, например, интеграция с MS Test меня не очень радует. Чтобы запустить отдельный тест, нужно открывать сгенерированный код и запускать его оттуда. Для нормальной работы еще необходимо создавать отдельно списки Ordered Test.

Но, с NUnit у меня таких проблем нет.

Еще, иногда, Specflow не правильно находит привязки. Вот, в примере выше, мне пришлось сделать привязки с одинаковым текстом для When и Given, чтобы обойти эту проблему.

Но, все равно меня радует в Specflow подсветка синтаксиса, возможность перейти по F12 из фичи на ее Step Definition и автодополнение тоже хорошо работает.

Хотя, я NBehave тоже заинтересовался. Интересно посмотреть что это за зверь на практике.

 

[KaNoN]

 

Возможность такого рода переиспользования GWT в Cucumber – я считаю грязным хаком.

Почему хаком? – потому что есть файл .feature, который содержит тест фичи и это специальное место для того чтобы вот так обычным текстом писать And Click on the "Reports" link

Есть файл step definition – там должен быть код, без «хрупкого» текста. Я уверен в том, что код нельзя мешать с обычным текстом.

Тут дело скорее в используемых механизмах. В SpecFlow привязка текста к коду делается посредством атрибутов. В Cucumber это обеспечивается отдельными конструкциями. По сути у нас вырисовывается 3 уровня:

* Уровень текста

* Уровень привязок

* Уровень кода

И все это представлено отдельными ресурсами. В такой постановке переиспользуемость текста вполне уместна + опять же, как вы упомянули, иногда есть необходимость разные фразы привязать к одному и тому же куску кода. То есть получить своего рода "синонимы". Поскольку в Руби не используется механизм аттрибутов, то вот такая штука как раз является альтернативой. Так что я бы это назвал не хаком, а особенностью реализации движка для конкретного языка. К тому же данная возможность заявлена открыто.

 

Почему грязный? – потому что в тексте Given\When\Then есть всегда неоднозначность.

Вот например, читая строку:

And 'Click on the "Reports" link'

 Я могу подумать, что "Reports" – может быть параметром для какого-нибудь шага. А, на самом деле, это может быть не так. По тексту я не могу определить, как будет работать шаг, и какие параметры он принимает, и мне придется лишний раз идти в код нужного мне шага, чтобы выяснить это.

На самом деле подобные штуки сразу лучше оговаривать на уровне стандартов, ведь Given\When\Then фразы обычно несут разный смысл, хотя действия могут быть одними и теми же. Но это не самое страшное. Самое веселье, когда используются кавычки или знаки препинания. Тогда без стандартов даже на самые тривиальные операции будут плодиться отдельные текстовые конструкции. Например:

When I click on reports link

When I click the reports link

When I click on the "Reports" link

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

А что за ограничения Specflow?

Я уже упоминал, что воспоминания не совсем свежи, но вы вот кое-что привели + то, что сам помню:

1) Трудности с MS Test запуском

2) Не так гибко подхватываются нужные выражения, например в Cucumber достаточно написать When /click on \"(.*)\" link/ и эта регулярка будет подхвачена при фразе When "I click on "reports" link on the top navigation menu". Пусть на самом деле за этой фразой стоит более общий метод, который кликает на ссылке на текущей странице, но вот такие добавки повышают читаемость.

3) Cucumber является не просто движком, но и сам является раннером. То есть, есть своя командная строка Cucumber-a, позволяющая запускать тесты (NBehave кстати тоже имеет утилиту, которая запускает тесты командной строкой, надо только нужную сборку указать). Но помимо этого есть встроенные репортеры, позволяющие выводить в результатах и текстовые конструкции, которые были задействованы. Поскольку SpecFlow по сути генерирует код для MS Test, NUnit и других подобных движков, то и репорты будут такими же, как в этих движках. Соответственно, если нужно в репорте отображатьшаги выполнения, то придется кастомизировать репортер.

Там хватает заморочек. Вообще, я долго крутился вокруг выбора между SpecFlow и NBehave. По сути оба этих решения "кастрированы" с разных сторон. Что-то есть в одном решении, но нет в другом. Ну, у меня по-крайней мере сложилось такое мнение.

 

[dzhariy (Дмитрий Жарий)]

Но помимо этого есть встроенные репортеры, позволяющие выводить в результатах и текстовые конструкции, которые были задействованы. Поскольку SpecFlow по сути генерирует код для MS Test, NUnit и других подобных движков, то и репорты будут такими же, как в этих движках. Соответственно, если нужно в репорте отображатьшаги выполнения, то придется кастомизировать репортер.

 

 С этим согласен, без кастумезации, Specflow + MSTest или NUnit логируют шаги тестирования как обычный тест. Но, с другой стороны, и это уже не мало. Дело в том, множество людей не очень любят добавлять дополнительное логирование в свои тесты и те логи, которые Specflow делает автоматически (Что такой-то степ начат… завершен успешно или с ошибкой) уже может оказать огромную помощь в исследовании результатов фейла тесткейса.

Ну и у компании-разработчика Specflow есть продукт Speclog (http://www.speclog.net/watch/), который платный, но предоставляет целый комплекс инструментов от раскраски логов Specflow до Continuous Integration и поддержки идеи «Живой документации» (http://www.youtube.com/watch?v=XTUf0LrQ-oc).

И с другими пунктами об ограничениях Specflow я полностью согласен.

 

опять же, как вы упомянули, иногда есть необходимость разные фразы привязать к одному и тому же куску кода. То есть получить своего рода "синонимы". Поскольку в Руби не используется механизм аттрибутов, то вот такая штука как раз является альтернативой. Так что я бы это назвал не хаком, а особенностью реализации движка для конкретного языка. К тому же

 

 На счет Ruby и Cucumber, я немного погуглил, и действительно несколько людей рекомендуют именно такой «текстовый» вызов одного шага из другого. В Языке Руби действительно нет атрибутов, но вполне возможен следующий вариант декларации шага (в Руби), который в данный момент не реализован в Cucumber:

 

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }When /I click on reports link/, /I click the reports link/, /I click on the "Reports" link/ do

Click on reports link here!

end
{/syntaxhighlighter}

Язык Руби не ограничивает такой синтаксис. Но, скорее всего, у разработчиков Cucumber были свои мотивы не реализовывать подобный функционал.
В общем, мне стало интересно, и я им вот такой ишшу накатал:

https://github.com/cucumber/cucumber/issues/213

 

 

 

 

 

[rpwheeler]

Исходя из тестов SoapUI, использовавшихся в проекте, где я работал, "один тест - одна проверка" нецелесообразно. Тест(-кейз) обычно включает в себя несколько шагов и проверок, и может завалиться на одном из этих шагов. Ничего страшного в этом нет.

[polusok (Mykhailo Poliarush)]

это еще раз показывает, то что не стоит ровнять всех под одну косынку.

проверка xml или веб-сервиса врядли можно представить только с одной проверкой, иначе там было тысячи тестов