Добрый день,
заранее хочу извиниться так как тема несколько провокационная, но все же представлю вам статью http://www.jimmycuadra.com/posts/please-don-t-use-cucumber
Да, тема холиварная, но все же интересно знать мнения участников automated-testing.info
Согласен на 100%
После Огурца перешел на Рспек и радовался как ребенок, так как в какой-то момент мои глобальные файлики со step_definitions становились просто огромными и неповоротливыми, в них без крутых РубиМайновских Ctrl+B ориентироваться было вообще невозможно. Вообщем идея не плоха, конечно, но оооочень редко применима по крайней мере на проектах где работал я. Максимальный профит от данного тула возможен в случае когда сценарии пишет один а "определения" для них - другие
Отличная статья!
Мы по тем же причинам создали библиотеку Selenide. Все фреймворки для Java были такими же монструозными, как тут описывается Cucumber, а нам хотелось сделать что-то простое и практичное.
У меня тоже есть похожая гневная статья про Thucydides: http://asolntsev.livejournal.com/66565.html
Я для себя выделил такой тезис: If you're not really following BDD practices, and your non-technical stakeholders are not reading or writing Gherkin, Cucumber is wasting your developers' time and bloating your test suite.
Я бы очень хотел узнать мнения Димы Жария по этому поводу,
Ведь он очень доволен SpecFlow/BDDfy-альтернативой огурцу.
Имеет ли смысл, по его мнению, использование этих инструментов в случаях когда никто кроме девелоперов тесты не читает/пишет?
Ну не всегда ж только девелоперы будут писать тесты, да и всегда есть момент, когда приходят новые люди на проект, которые не писали фреймворк, им будет проще понять логику тестов, которые описаны "по-человечески"
Я прочитал статью, и нашел в ней нечто большее, чем просто выброс желчи. Чтобы ответить на этот вопрос, давайте разделим то, что есть в Cucumber на несколько частей.
Behavior-Driven Development
This doesn't allow for the real red-green-refactor cycle from the outside in of the BDD philosophy, but in my experience, developers tend to avoid the test-first approach with Cucumber simply because it's so painful to use. If you're not really following BDD practices, and your non-technical stakeholders are not reading or writing Gherkin, Cucumber is wasting your developers' time and bloating your test suite.
Скажу сразу, что ни один BDD инструмент не гарантирует того, что у вас создастся и наладится BDD-процесс. Это всего лишь инструмент!
А подход «сверху-вниз» (outside-in) не обязывает вас к циклу «red-green-refactor». Red-green-refactor – это требование Test-Driven Development, это инструмент разработчиков, а точнее одного разработчика, который сначала тест напишет, а потом напишет код, а потом этот код улучшит и перейдет к следующему тесту.
Да, BDD начинался с того, что это был вспомогательная техника для программистов, но, сейчас сам подход очень разросся и включил для себя еще несколько техник и методологий, охватывающих весь цикл разработки. Важно то, что в BDD нет жестких правил, а есть несколько рекомендаций, которые могут работать или не работать в определённых условиях. Исходя из этих условий нужно выбирать и инструмент.
Язык Given/When/Then (Gherkin)
Мне лично этот «язык» нравится без всяких инструментов. А на некоторых миттингах на проекте, у нас есть человек, который никогда не интересовался кукумберами/спекфловами и прочими инструментами, никогда не слышал о BDD, но очень часто использует When и Then для объяснения проблемы (неправильной работы системы). Мы иногда шутим: «она говорит в BDD-стиле».
Язык Gherkin, в данный момент, я считаю самым природным способ описать проблему в системе или требование. В этом языке нет ничего плохого, но только в том случае, если вы умеете на нем разговаривать. Этот язык позволяет мне задумывается о том, что я пишу и лучше структурировать текст.
Я на нем пишу баг-репорты:
http://blog.zhariy.com/2012/12/given-when-then.html
И у меня еще не было такой ситуации, когда баг-репорты возвращали потому, что не могли понять. Недавно смотрел, таких отчетов у меня около 150 из 400.
Нечего говорить, что этот язык недостаточно английский (это я автору статьи). Отличный язык. Вполне применим не только в Cucumber, но и в Ворде/Екселе/Баг-трекере.
Инструменты и цели
Не секрет, что те или иные инструменты мы используем для достижения той или иной цели. Каждый инструмент имеет свою «сложность», которая, опять же, зависит от контекста.
Тут автор статьи очень правильно сказал о «техническом долге», под которым, я думаю, он подразумевал сложность и количество действий, для того чтобы добавить новый шаг.
Плюс, со временем, количество шагов растет, и управлять ими становится невыносимо сложно.
Я не знаю, есть ли такая фича в Cucumber, но в Specflow специально добавили атрибут Scope для того, чтобы отдельно можно было писать шаги для конкретной фичи, и не делать их глобальными.
Кроме того, в отличии от Cucumber, в Specflow реализована классная интеграция с Visual Studio, переход из шага в его реализацию по горячей клавише, менее болезненный редактор таблиц, который поддерживает авто форматирование.
Cucumber – это в первую очередь, инструмент коммуникации внутри команды. Если эта цель не осуществлена, т.е. сценарии читает лишь один человек – то, может быть, стоит задуматься о смене инструмента.
На Cucumber можно сделать свой Keyword-driven Framework, или как его иногда называют – DSL.
Это упрощенный язык (содержащий минимум ключевых слов), который может быть более понятен нетехническим людям. И если эти люди действительно считают что писать в feature файле для них легче чем в Ruby – то это может быть вариантом.
Да что тут говорить, просто попробуйте создать один и тот-же более или менее сложный тест на разных инструментах, и выберете тот, который лучше этот делать здесь и сейчас, тот который вам больше нравится и решает задачу лучше.
Кроме того, отличные результаты достигаются использованием нескольких инструментов одновременно. Многие люди советуют использовать Cucumber и RSpec в одном проекте, почему бы и нет?
Свой фреймворк
Я лично за то, что в случае системно-интеграционного тестирования (через браузер, тестирование через интерфейс приложения) – был свой фреймворк. Только одни пейдж-обжекты могут обеспечить достаточный уровень абстракции, сократить усилия на поддержку.
Посмотрите, как реализованы шаги у этого фреймворка (Ruby):
https://github.com/wikimedia/qa-browsertests
SeConf: http://new.livestream.com/seleniumconfA/TrackA/videos/21346814
Возможно, где-то и есть недостатки, но выглядит очень не плохо.
А если шаг в Cucumber будет сводится к вызову одного или двух методов вашего фреймворка, то и необходимость в переиспользовании шагов в Cucumber отпадет сама собой. И те же методы вы сможете переиспользовать в RSpec или другом инструменте.
На недавно завершившейся Selenium Conference прозвучал доклад о реализации отдельного десктопного приложения для полу-автоматизированого тестирования. Это приложение использует Webdriver для заполнения некоторых самых важных и огромных форм. Интересно то, что само приложение переиспользует функции фреймворка автоматизации, который так-же используется в авто-тестах. Т.е. добавляя новую функциональность в приложение – эта же функциональность добавляется в авто-тесты, и наоборот.
http://new.livestream.com/seleniumconfA/TrackA/videos/21336364
Что я могу посоветовать, если вы надеетесь на долгосрочную перспективу работы с автоматизацией – инвестируйте в свой тестовый фреймворк. В таком случае вам будет просто не важно что «прикрутить сверху». Cucumber – нет проблем. Захотите полностью перейти на RSpec? – через день или два миграция будет завершена.
Из моего опыта, 80% результата, т.е. хорошего кода, дают PageObject’ы.
А дальше, часто используемый код с Пейджобжектами можно укрупнить в отдельные шаги.
Признак хорошего фреймворка, это когда ваши тесты не знают о том, что используют Selenium или Capybara.
В заключение:
К оригинальной статье я отношусь позитивно, потому что позиция автора – аргументирована. Прислушайтесь к аргументам, но не к выводам. Сделайте свои выводы.
Инструмент хороший – если с ним удобно работать и он решает вашу задачу.
Используйте несколько инструментов.
Сделайте все, чтобы замена одного инструмента другим – не было губительным для проекта.
Ссылки на упомянутую Selenium Conf. Там много интересного:
http://new.livestream.com/seleniumconfB/TrackB/videos
http://new.livestream.com/seleniumconfA/TrackA/videos
UPD: только что обнаружил, что на SeConf был еще один доклад, который я только начал смотреть. Как раз про Cucumber и про хорошие практики его использования:
http://new.livestream.com/seleniumconfB/TrackB/videos/21352248
testomat.io управление авто тестами