Сегодня перечитывал хорошие слайды о тестировании и в том числе автомтизации в agile проектах. Cлайд по ATDD говорит следующее:
Т.е. договариваемся - на нас выделают время в том числе, уточняем - что мы должны покрыть разрабатываем - по хорошему, сначала пишутся тесты или прототипы, а потом код показываем.
Только вот в реальной жизни так не получается. Я работаю на удаленном проекте. Разрабатываем сайт. Как-то по этой схеме работа вообще не идет.
Получается так: прибежал главный и сказал делаем, обсуждаем, делаем, обсуждаем, делаем, а иногда меня как тестера (конечно же такой роли нет в agile) могут и не включить в разговор, а потом раз и код уже на продакшине без моего ведома :). Есть главный программист, который юнит тесты с принципе отказывается делать, даже немогу понять почему.
Собственно вопрос, совпадает ли схема указанная выше с реальной жизнью у вас?
В добавок, припоминается мне фраза: "Automating chaos just gives faster chaos." Что переводиться как "автоматизация хаоса просто дает более быстрый хаос".
Я так понял, что эта схема описывает BDD (Behavior Driven Development) подход к написанию ?
На проекте, где я сейчас, отказались от BDD, но работаем по TDD. Но наслышан от друзей, которые на проектах, где вначале пишутся тесты на "геркине" (Gherkin) бизнес аналитиками, а дальше дело за разработчиками.
В целом ничего критично отличного от TDD, главное чтобы заказчик был заинтересован в подобного рода тестировании.
Вот с теми программистами, которые не понимают смысла юнит-тестов, очень тяжело. Даже если они и начнут их писать, то толку от таких тестов будет мало.
Очень похоже, но это не BDD, а Acceptance TDD. Различия только в том, что в БДД, код уже представляет выполняемые требования, посредством описания системы человечиским языком. В АТТД, просто оговаривается, что важно и нужно для заказчика и дальше пишутся оговариваются, какие тесты нужно будет прогнат для того, чтобы функционал был принят заказчиками в конце.
А по поводу, юнит тестов, да тут действительно очень тяжело, сам это почувствовал. Просто, если нет юнит тестов, то и гибкости никакой нет, т.е. вносить изменения в код просто не получается. Проблема, отчасти, что это удаленный проект и делать изменения "умов" очень тяжело через почту или коммуникатор.
Читал недавно Тестинг Планет и увидел отображение правильных процессов в Agile и автоматизации на основании спецификаций с примерами. Захотелось показать. Автор - Gojko Adzi (http://gojko.net/)