Что пишут в блогах

Подписаться

Очные тренинги

Все очные тренинги
Оставь заявку на тренинг в своем городе

Онлайн-тренинги

  • Все онлайн-курсы
  •  

    http://software-testing.ru/about/authors/9-barancev

    Разделы портала

    VIP-вакансии

    Наши партнёры

    www.it4business.ru

    UML2.ru

    SysIQ Inc.

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

    Выступление Алексея Баранцева на 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 приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

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

    Обсудить в форуме

     

    Добавьтe Ваш комментарий

    Ваше имя (псевдоним):
    Ваш адрес почты:
    Заголовок:
    Комментарий: