Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD

Выступление Алексея Баранцева на AgileDays-2011

Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.

Однако здесь есть два больших подводных камня.

Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.

Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

Видеозапись доклада можно посмотреть здесь.



Читать дальше

Ух ты. А я все думал как про это и без матов написать.

Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты

Никто не заставляет программировать в паттерне given-when-then и в табличках. Каждая команда выбирает и
договаваритается о том что им удобнее. Николай Алименков правильно упоминул Concordion. Там нет таких ограничений.

если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

В таком случае PO - идиот. Нужно обновлять приемочные тесты и дописывать чего не хватает PO.

Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.

Да, но для класического скриптового языка тоже нужно кодировать.
Зато можно скрыть многие технические детали от QA и дать им доменный язык программирования для тестирования.

Зато можно скрыть многие технические детали от QA и дать им доменный язык программирования для тестирования.

Ну да, и проверки, которые делаются, тоже придется скрыть. Вместе с техническими деталями. Ну или это это будет тесты и проверки на уровне "Hello World"
Зачем QA доменный язык программирования? Сколько реально полезных тестов они смогут написать с его использованием? А сколько стоит поддержка такой возможности? И сколько стоит поддержка тех тестов, которые напишут QA?
Без тесного взаимодействия QA с автомтатизаторами не получится написать хороших автотестов все равно. А при наличии тесного взаимодействия необходимость в специальном доменном языке отпадает.

kos32, вопрос в профите и скрытых издержках. Часто в итоге получаем что проще так тесты писать чем маяться с фитнесом и огурцами. Ну или свой фрейм ваять, что тоже ок.

Каждая команда выбирает и договаваритается о том что им удобнее. Николай Алименков правильно упоминул Concordion. Там нет таких ограничений.

Кстати, забыл спросить у Николая, спрошу здесь -- для Concordion сделали таки визуальный редактор или нет?
Если нет -- не будут им пользоваться PO. Не будут и всё тут.

Вообще-то, надо признать, что тестировщики не первые пытаются ходить по этим граблям. У программистов уже была эта эпопея, правда, в более мягком варианте -- погуглите и почитайте про "литературное программирование" (literate programming), на которое Кнут возлагал большие надежды, но которое "не взлетело". Очень красивая идея, очень убедительно написано про то, как здорово всем этим пользоваться. Но -- не взлетело.

понравилось обсуждение
интересно

Алексей, Вы не могли бы добавить, чем Ваше обсуждение с девушкой закончилось?

Каждый остался при своём мнении, это же вполне очевидно :)