Аннотация
- Докладчик
- Алексей Баранцев
Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.
Однако здесь есть два больших подводных камня.
Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?
Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.
Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="http://player.vimeo.com/video/22491632?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
В качестве очередного доклада для посещения я выбрал выступление Алексея Баранцева про плюсы и минусы BDD и ATDD. Мы до этого выступали с Алексеем на нашей конференции Selenium Camp и у меня остались очень позитивные воспоминания от общения с ним. В докладе больше было все таки минусов, нежели плюсов. Я очень пожалел, что на этом докладе не присутствовали многочисленные поклонники BDD во всех его проявлениях, которых так много на технических конференциях. Они бы забросали докладчика камнями. Но, к счастью, представителей Cucumber и FitNesse было немного. В зале нашлось несколько участников с противоположенным опытом, которые получили огромные преимущества благодаря использованию ATDD и BDD, поэтому в секции вопросов и ответов было жарко.
©
- Докладчик
- Алексей Баранцев
- Компания
- Software-Testing.Ru
- Презентация
- Документ на prezi.com
Несколько вебинаров Алексея Баранцева я ранее смотрел и слушал (вебинары понравились), поэтому было очень интересно посмотреть на него вживую. Ожидания, в принципе, оправдались.
Доклад оказался очень оригинально оформлен с помощью сервиса prezi.com, поэтому не видевшим такое ранее можно рекомендовать посмотреть (перейти по ссылке и последовательно пощелкать на кнопку Play для перехода от слайда к слайду).
Рассказывалось про продукты Cucumber («огурец») и Fitnesse («фитнес», интересная статья на Хабре) (последний мы пробовали использовать, он даже понравился) для автоматизации приемочного тестирования (точнее, докладчик предлагал их использовать скорее для ведения требований Product Owner'ом).
Общим итогом доклада и ответом на вопросы (мы тоже Алексею вопросы задали) является, что
- вышеуказанные два продукта не рекомендуется использовать чисто для тестирования;
- при их использовании (обычно в связке с Jemmy, UISpec и т.д.) нужно тестировать редко меняющиеся бизнес-функции, а не интерфейсные функции.
Доклад полностью оправдал ожидания, Баранцев не разочаровал.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
