Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Кто-то может обьяснить разницу между TDD и BDD? Это же одно и тоже?! Ну немного акцентируют внимание на более разумном выборе тестов. Но это же не причина еще один 3 буквенный базворд придумывать.
Мне вот подумалось, что неплохо было бы коротенько рассказать историю возникновения подхода/методологии BDD. И я не стал себя останавливать.
Все началось с того, что у одного чела, Дэна Норта, не хватило фантазии ответить, входе своих тренингов по TDD, на один простой вопрос: а какие тесты мы должны вообще написать, чтобы было достаточно для покрытия функциональности?
И тут, к нему пришло прозрение: а давайте напишем в заголовках тестов, не что мы проверяем, а то, что мы ожидаем от работы еще не реализованной функциональности. Т.е. вместо того, чтобы заголовок теста звучал как: протестировать_что_sqrt_от_16_равно_4(), появились тесты:
должен_вычислять_квадратный_корень_для_положительных_чисел()
должен_вычислять_квадратный_корень_для_отрицательных_чисел()
и т.д.
Конечно же, и в этом случае, некоторых тестов может не хватать, но, теперь можно посмотреть в код тестов и выявить, какого кейса не хватает. Когда написано почти-человеческим языком, а не магией чисел — как-то читать легче.
Да, вы заметили, что заголовки теста теперь стали неким подобием спецификации/требованиями к классу или методу? Так оно и есть. И Бдышь! Так, около
Подобные идеи посещали головы людей и раньше, но, первым кто все описал, был Дэн Норт:
dannorth.net/...ntroducing-bdd
Кроме этой простой идеи с именами тестов, Дэн также описал то, что тесты написанные в таком духе, помогают и другим участникам команды лучше понимать функциональность, и в итоге, даже между собой разговаривать на «общепонятном языке» (ubiquitous language).
Если вы дочитали до этого места, и считаете, что ubiquitous language — это какая-то фигня. То, я прошу вас представить себе... собаку. Вот закройте глаза — и представьте себе собаку. Зачем? Узнаете в конце это поста этого текста. А можно, и сейчас пролистать.
В общем, наступил Дэн Норт своей статьей на мозоль проблемы взаимопонимания внутри команды. А заболела эта мозоль где-то за океаном, у Гойко Аджича ( gojko.net ), который этой проблемой всерьез и занимался. И тут-то он и написал книгу: Specification by Example (specificationbyexample.com). Которая как раз и подсказывает как достичь этого взаимопонимания, ubiquitous language, и не просто внутри команды, а внутри stackholder’ов, т.е. между заинтересованными лицами. Вот тестировщик, заинтересованное лицо? — Конечно, ведь он в команде работает и ЗП за это получает и хочет чтобы программисты написали успешный продукт. А программист? А заказчик/продуктовнер/продукт менеджер? — Ответ: Да. И настолько это была прикольная идея, спецификация через пример, что стала подмножеством BDD.
Дэн Норт и Гойко Аджич говорили еще об одной идеи. О том, что требования должны идти из потребностей бизнеса. Т.е., чтобы разработчики не фигачили всякую фигню, которая никогда никому и нужна не будет, а делали все для хорошего решения бизнес-задач вовремя. Учитывая то, что Дэн был больше человеком техническим, Гойко просто удалось эту идею лучше донести. Вот что означает этот «outside-in» в определении BDD.
Спускаясь с небес, давайте вернемся к инструментам. Наверное, это первое, что мы видим, и после чего, немногие из нас продолжают копать саму идею. Jasmine, Cucumber, BDDfy, Specflow и множество других... это... инструменты, которые помогают воплощать подходы BDD в жизнь.
Это не значит, что если вы возьмете молоток, то сразу же забьете гвоздь. Точно так же с BDD-инструментами. Они помогают работать людям, которые понимают теорию BDD. Но, вряд ли у вас получится что-то BDD-шное, только потому, что вы используете инструмент.
И вот вам еще один резкий поворот. Есть крылатая фраза «BDD is TDD done right». Которую многие понимают, как «BDD — это круто, а ваш TDD — фуфло». На самом же деле: BDD — это попытка сформулировать лучшие практики TDD. Т.е. BDD пересекается с TDD, предлагая хорошие практики решения некоторых проблем.
И вот еще резкий поворот. Статья от Дэна Норта о том, что BDD — это как TDD, но, если...
dannorth.net/...is-like-tdd-if
Я надеюсь, что мне удалось вас окончательно запутать, либо внести ясность.
----
* не знаю как вы, а я представил себе таксу. Я — тестировщик, и буду тестировать то, что вы напишите — как таксу. Если вы представили бульдога... нет, это не ваша проблема. Просто, мы говорим на разных языках, а не на... кхем... ubiquitous language
Еще одна попытка назвать очередной подход к решению задачи и сделать вокруг этого некий маркетинг.
Может мне потрудиться/попытаться назвать все варианты сразу?!(берем язык С++)
1. Можно писать тесты к интерфейсу, а потом реализацию.
2. Можно писать реализацию, а потом тесты.
3. Можно написать на процедурном подходе, а потом обвернуть все это в ООП.
4. Можно сразу написать на ООП.
5. Можно писать все сразу на ФП
6. Можно писать сразу конкретные классы, а потом писать базовый, обобщая логику.
7. Можно сразу писать базовый класс, а потом от него наследоваться.
8. Можно написать все на ПП, а потом переписывать на ООП.
9. Можно все втулить в пространства имен.
10. Можно вместо пространств имен, писать префикс каждому имени.
11. Можно разделить тестирование, разработку, реализацию, проектирование и все программисты будут делать одно, этап за этапом, но вместе.
12. Можно разделить так чтобы часть программистов только тестировала, а друга реализовала.
13. Можно сделать оптимизацию по скорости, но убив память, добавляя таблицу косинусов, синусов, тангенсов и т.д.
14. Можно сделать оптимизацию по объему, но убив скорость, добавляя ручной расчет, с нуля, нового значения косинусов, синусов, тангенсов.
15. Можно сделать оптимизацию по обоим характеристикам, но убив простоту системы, добавляя механизм кеширования наиболее встречаемых значений косинусов, синусов, тангенсов и т.д.
16. Можно сделать адаптивную оптимизацию по всем, но убив статичность кода и его читабельность, добавляя в систему адаптивные системы с самообучением и новые условные переходы, которые решают по производительности, по статистике какие значения записывать в памяти, а какие считать на лету или какие задействовать на определенной архитектуре.
17. Можно потратить половину время написав неполный проект, чтобы потом продумать детальнее архитектуру.
18. Можно потратить все время на обдумывания архитектуры, а потом быстренько вбить код.
19. Можно не тратить и время и сразу вбивать код, но потом тратить время на войну с кривой архитектурой.
20. Можно начинать с фронтэнда и показывать сразу заказчику морду, а потом к нему дописывать логику с бэкэндом.
21. Можно начинать с бэкенда, а потом просто выводить на фронтэнд, но в конце разработки.
22. Можно написать свои фреймверки и потом использовать их на различных платформах монолитно. И затачиваться под себя
23. Можно использовать чужие, готовые фреймверки, но потом подстраиваться под их прихоти, и разруливать зависимости на различных платформах.
24. Можно писать на Java и не думать о кроссплатформенности, но забыть про скорость, про выигрыш в объеме и зависеть от прихотей JVM. Ждать поддержки JVM на новой платформе.
25. Можно писать в машинных кодах, но для каждой платформы свои варианты. Но забыв про оптимизацию, про зависимость от фреймверков, VM, и иметь всю мощь под рукой и пространство для творчества.
26. Можно написать программу для работы с деревьями запихнув все в один класс.
27. Можно написать программу для работы с деревьями сделав хранение дерева в одном классе, а доступ к узлам через отдельные итераторы. Разбив на классы.
28. Можно написать setPos(int x, int y);
29. Можно написать setPosX(int x); setPosY(int y);
30. Можно написать оба варианта 28 и 29, и нагрузив, тем самым, код избыточным функционалом.
31. Можно написать весь функционал сразу на всякий пожарный, на будущее.
32. Можно дописывать функционал по мере необходимости, но при этом вспоминая код двухнедельной давности.
33. Можно разделить программистов и дать им некий интерфейс и песочницу, где они будут реализовывать свою логику в отрыве от остальных и не мешая им.
34. Можно разделить программистов и дать им более расплывчатые задачи, ,которые налезают на то что делают другие, и ориентироваться на общие внешние фреймверки, которые используют другие члены команды.
35. Можно обучить программистов тестировать, оптимизировать, писать документацию, общаться с заказчиком, писать ТЗ.
36. Можно разделить на отдельные профессии, но при этом потратив на склеивание людей разной подготовки и разного взгляда на проблему.
37. Можно двигаться от общего к частному.
38. Можно двигаться от частного к общему.
39. Можно все вышеперечисленные варианты комбинировать, получив свободу, но при это утратив чувство стиля, и не понимать что вообще творится в процессе разработки ПО
40. Можно следовать строго одной концепции из вышеперечисленных вариантов, но при этом утратив свободу выбора и гибкость маневрирования.
Можно получить число 4 разными вариантами:
2 + 2 = 4
sqrt(16) = 4
2 * 2 = 4
32 / 8 = 4
(2 * 1) + (2 * 1) = 4
2 * (1 + 1) = 4
10 — 6 = 4
log2(16) = 4
0 * 0 + 4 + 0 * 2 + 1 — 1 = 4
2’564’545’465 — 2’564’545’469 = 4
... и так до бесконечности.
Так может сразу сядем, тяпнем пивка для храбрости и назовем все подходы наперед своими именами??? Неа!!! А че ждать?! Ведь и так ясно, сколько вариантов построения процесса разработки может существовать. Посчитать комбинации, вывести их и дать им имена свои, а потом тулить как «Смотри, заказчик! Мы тут новую методологию придумали. Гони бабки!». Наперед назвать. Программирование скатывается на уровень с тенденциями моды.
Сумма очков во Вселенной всегда равна нуля, как бы вы не рыпались. Уравнение на то и уравнение, что если все поставить в левую часть, то все будет равняться нулю.
Вот вам тождество Эейлера. Формула Бога для создания всего мира и управлениями почти всеми процессами.
tinyurl.com/pn6zj5c
TDD — делать вещи правильно. BDD — делать правильные вещи. Они не взаимозаменяемы.
Еще одна попытка назвать очередной подход к решению задачи и сделать вокруг этого некий маркетинг.
Может мне потрудиться/попытаться назвать все варианты сразу?!(берем язык С++)
1. Можно писать тесты к интерфейсу, а потом реализацию.
2. Можно писать реализацию, а потом тесты.
3. Можно написать на процедурном подходе, а потом обвернуть все это в ООП.
4. Можно сразу написать на ООП.
5. Можно писать все сразу на ФП
6. Можно писать сразу конкретные классы, а потом писать базовый, обобщая логику.
7. Можно сразу писать базовый класс, а потом от него наследоваться.
8. Можно написать все на ПП, а потом переписывать на ООП.
9. Можно все втулить в пространства имен.
10. Можно вместо пространств имен, писать префикс каждому имени.
11. Можно разделить тестирование, разработку, реализацию, проектирование и все программисты будут делать одно, этап за этапом, но вместе.
12. Можно разделить так чтобы часть программистов только тестировала, а друга реализовала.
13. Можно сделать оптимизацию по скорости, но убив память, добавляя таблицу косинусов, синусов, тангенсов и т.д.
14. Можно сделать оптимизацию по объему, но убив скорость, добавляя ручной расчет, с нуля, нового значения косинусов, синусов, тангенсов.
15. Можно сделать оптимизацию по обоим характеристикам, но убив простоту системы, добавляя механизм кеширования наиболее встречаемых значений косинусов, синусов, тангенсов и т.д.
16. Можно сделать адаптивную оптимизацию по всем, но убив статичность кода и его читабельность, добавляя в систему адаптивные системы с самообучением и новые условные переходы, которые решают по производительности, по статистике какие значения записывать в памяти, а какие считать на лету или какие задействовать на определенной архитектуре.
17. Можно потратить половину время написав неполный проект, чтобы потом продумать детальнее архитектуру.
18. Можно потратить все время на обдумывания архитектуры, а потом быстренько вбить код.
19. Можно не тратить и время и сразу вбивать код, но потом тратить время на войну с кривой архитектурой.
20. Можно начинать с фронтэнда и показывать сразу заказчику морду, а потом к нему дописывать логику с бэкэндом.
21. Можно начинать с бэкенда, а потом просто выводить на фронтэнд, но в конце разработки.
22. Можно написать свои фреймверки и потом использовать их на различных платформах монолитно. И затачиваться под себя
23. Можно использовать чужие, готовые фреймверки, но потом подстраиваться под их прихоти, и разруливать зависимости на различных платформах.
24. Можно писать на Java и не думать о кроссплатформенности, но забыть про скорость, про выигрыш в объеме и зависеть от прихотей JVM. Ждать поддержки JVM на новой платформе.
25. Можно писать в машинных кодах, но для каждой платформы свои варианты. Но забыв про оптимизацию, про зависимость от фреймверков, VM, и иметь всю мощь под рукой и пространство для творчества.
26. Можно написать программу для работы с деревьями запихнув все в один класс.
27. Можно написать программу для работы с деревьями сделав хранение дерева в одном классе, а доступ к узлам через отдельные итераторы. Разбив на классы.
28. Можно написать setPos(int x, int y);
29. Можно написать setPosX(int x); setPosY(int y);
30. Можно написать оба варианта 28 и 29, и нагрузив, тем самым, код избыточным функционалом.
31. Можно написать весь функционал сразу на всякий пожарный, на будущее.
32. Можно дописывать функционал по мере необходимости, но при этом вспоминая код двухнедельной давности.
33. Можно разделить программистов и дать им некий интерфейс и песочницу, где они будут реализовывать свою логику в отрыве от остальных и не мешая им.
34. Можно разделить программистов и дать им более расплывчатые задачи, ,которые налезают на то что делают другие, и ориентироваться на общие внешние фреймверки, которые используют другие члены команды.
35. Можно обучить программистов тестировать, оптимизировать, писать документацию, общаться с заказчиком, писать ТЗ.
36. Можно разделить на отдельные профессии, но при этом потратив на склеивание людей разной подготовки и разного взгляда на проблему.
37. Можно двигаться от общего к частному.
38. Можно двигаться от частного к общему.
39. Можно все вышеперечисленные варианты комбинировать, получив свободу, но при это утратив чувство стиля, и не понимать что вообще творится в процессе разработки ПО
40. Можно следовать строго одной концепции из вышеперечисленных вариантов, но при этом утратив свободу выбора и гибкость маневрирования.
Можно получить число 4 разными вариантами:
2 + 2 = 4
sqrt(16) = 4
2 * 2 = 4
32 / 8 = 4
(2 * 1) + (2 * 1) = 4
2 * (1 + 1) = 4
10 — 6 = 4
log2(16) = 4
0 * 0 + 4 + 0 * 2 + 1 — 1 = 4
2’564’545’465 — 2’564’545’469 = 4
... и так до бесконечности.
Так может сразу сядем, тяпнем пивка для храбрости и назовем все подходы наперед своими именами??? Неа!!! А че ждать?! Ведь и так ясно, сколько вариантов построения процесса разработки может существовать. Посчитать комбинации, вывести их и дать им имена свои, а потом тулить как «Смотри, заказчик! Мы тут новую методологию придумали. Гони бабки!». Наперед назвать. Программирование скатывается на уровень с тенденциями моды.
Сумма очков во Вселенной всегда равна нуля, как бы вы не рыпались. Уравнение на то и уравнение, что если все поставить в левую часть, то все будет равняться нулю.
Вот вам тождество Эейлера. Формула Бога для создания всего мира и управлениями почти всеми процессами.
tinyurl.com/pn6zj5c
2’564’545’465 — 2’564’545’469 = 4будет −4 а не 4
А еще на BDD можно посмотреть как на тандем TDD и DDD. Отличны продукт получается.
Кто-то может обьяснить разницу между TDD и BDD? Это же одно и тоже?!Да, это одно и тоже — потеря времени/денег.
КНу немного акцентируют внимание на более разумном выборе тестов. Но это же не причина еще один 3 буквенный базворд придумывать.Причина в деньгах. Все вариации TDD это способ выжать дополнительное бабло с заказчика. Это же элементарно — мало срубить с заказчика рейт за написанный на коленке код, нужно срубить бабло еще и за покрытие этого безобразия тестами. И пофиг, что 60% багов это ненаписанный код, который тестами покрыть нельзя по причине его отсутствия. Теперь, с новым баззвордом «BDD» можно срубить бабла не только за покрытие тестами работающего кода, но и еще и за описание работающих и отлаженных тестов, которые покрывают работающий и отлаженный код. Ну чё, ждем TBDD — бум тестировать формализованное описание работающих тестов, покрывающих работающий код.
Оно-то, конечно, так, вот только:
— некоторые удрюченные сказками ПМов умудренные жизненным опытом заказчики сами цепляются в глотку и требуют покрыть дерьмо газеткой код юнит-тестами, и порой реально легче типа чего-нибудь написать (даже если код по природе своей не может быть адекватно покрыт более чем наполовину), чем время от времени объяснять, что:
60% багов это ненаписанный код, который тестами покрыть нельзя по причине его отсутствия
— для некоторых девов это единственный способ сварганить сколько-нибудь приемлемый интерфейс пинаемого куска системы (речь, увы, не только о джунах).
покрыть существующий код тестами и TDD/BDD это разные вещи. Первое имеет смысл если постоянно вылазят регрешин баги.
логика конечно у вас супер-крутая, тесты — потеря времени и способ выжать дополнительное бабло. Из разряда «а что, сразу правильно писать не получается?»
Теперь, с новым баззвордом «BDD» можно срубить бабла не только за покрытие тестами работающего кода, но и еще и за описание работающих и отлаженных тестов, которые покрывают работающий и отлаженный код.Как я люблю
И пофиг, что 60% багов это ненаписанный код, который тестами покрыть нельзя по причине его отсутствия.Сразу 2 ошибки.
1). Кто сказал, что код вообще работает?Это философский вопрос. Правила четного количества ошибок никто не отменял. Один и тот же код может быть как правильным, так и ошибочным в зависимости от модели. И так далее. Короче, к TDD все эти рассуждения не имеют никакого отношения.
Если у Вас в команде 60% багов — это отсутствующая функциональность, то что-то тут не так.Это статистика. Не моя. 60% багов в любой системе — несуществующие пути. Покрыть их автоматическими тестами невозможно в принципе, зато ручным тестированием они ловятся на раз.
2). Почему внезапно нельзя покрыть тестами отсутствующий код?Потому что вариантов возможных путей минимум 2^n, где n это количество ветвлений.
Разница в том, что BDD — это хорошо, а TDD — это плохо.
А Слава КПСС — вообще не человек. (к)
А я ведь не шутил. Если взглянуть на TDD и его принципы, то видно, что код получаецца без особой инкапсуляции, так еще и настраиваемый простынями в несколько строк, чтобы инжектировать все, что необходимо. Как по мне, тдд отвратителен именно этим. В то же время, все эти пробелмы решает сама парадигма bdd, где тестируецца не отдельная функция, а отдельная юзер стори, посему не надо ничего инжектировать, не надо открывать проперти для чтения снаружи и прочие прелести ооп.
Возможно. Давайте приведу примеры задачи для тестирования, а вы расскажете, как надо реализовать тестирование.
Есть метод у объекта, который надо протестировать. Этот метод внутри себя создает два вспомогательных объекта двух разных классов и производит вычисления с их помощью. Как сделать объект с таким методом тестируемым и как надо протестировать этот метод?
Ну и в чем собсвенно проблема?
1) Если вспомогательные объекты не детали внутренней реализации, то их полное тестирование может проводиться отдельно. Тогда остается протестировать основной объект/метод на предмет правильного вызова вспомогательных. Технику расписывать?
2) Внутренние вспомогательные объекты можно отдельно тестировать сделав их package private (java). Ничего страшного в большинстве случаев не произойдет. Но если не хочется, то см. ниже.
3) Вспомогательные объекты и их взаимодействие можно тестировать опосредовано через вызовы метода внешнего объекта по технике второй части пункта 1), но с большим покрытием так как нужно достичь больше путей во внутренних объектах.
Вопросы? gist.github принимается.
P.S. на всякий случай: TDD не значит только unit. Just in case.
ПРостите, но TDD — это и есть unit tests. Либо уж попрошу пруф в студию, т.к. подобного вашему утверждению нигде не встречал.
1. Распишите. Я хочу понимать, как вы протестируете это дело, не нарушив энкапсуляцию или не создав двух инъекций, которые и служили пререквизитом моего тезиса о том, что TDD — кал. dou.ua/...-comment#411953
2. Не знаю особенностей ява. Будьте добры, на общечеловеческом.
3. Опосредовано нарушает основные законы unti-тестирования, которое и есть суть TDD. Код становицца BDD, т.к. вы уже тестируете поведение по спеку, а не отдельного юнита.
ПРостите, но TDD — это и есть unit tests. Либо уж попрошу пруф в студию, т.к. подобного вашему утверждению нигде не встречал.
Я ж говорю, налицо непонимание. TDD по определению — Test Driven Development. Где там U чтобы требовать только юниты? Если хочется подробнее — читаем классику. Например, Мартин Фаулер martinfowler.com/...evelopment.html . Есть обратные пруфы более авторитетные чем ОБС?
Остальные пункты я так полагаю теряют насущность.
TDD — это один из основополагающих элементов Экстремального программирования от Кента Бека, именно он — «папа» всея TDD.
а реализация JUnit — это совместное творение Бека и Эрика Гаммы.
Видя успех JUnit другие языки тоже захотели себе «фишку» и постепенно реализация стала называться XUnit, где
И? Проясните связь между первым и вторым фактом кроме того что и там и там участвует Бек?
TDD — подход. Вы можете хоть в main-е «тестировать» или писать адский велосипед, главное (по TDD) чтобы код тестировался автоматизировано (с минимальным участием) а вам был виден результат — да/зеленая или нет/красная.
xUnit — наиболее распространенная технология реализации модульных тестов.
Бек участвовал в обоих и после грандиозного запила xUnit он как бы прикрепился к TDD.
ок, как это противоречит тому что я сказал в ответе trimm?
и кстати
xUnit — наиболее распространенная технология реализации модульных тестов.
не только модульных, но и многих других. Как раз потому что «как бы прикрепился к TDD» встречаем все типы тестов вплоть до нефункциональных на базе xUnit. Пусть Unit в названии не пугает. Это была и есть основная цель, но тест запущенный в JUnit не классифицируется от того в unit-test.
ок, как это противоречит тому что я сказал в ответе trimm?
Прямо противоречит, т.к. я ни у Бека, ни у Фаулера поведенческого тестирования не видел. И хочу от вас пруфа именно этого вашего утверждения, что тдд кратно поведенческому тестированию в т.ч. Ибо для меня ТДД кратно юнит-тестам стало именно после чтения Бека под зад лет назад.
Бек использовал юнит тестирование как пример TDD.
для меня ТДД кратно юнит-тестам стало— вот и корень заблуждения.
ни у Бека, ни у Фаулера поведенческого тестирования не видел.чем поведенческое тестирование так сильно отличается от другого TDD? Почему нельзя BDD делать с помощью юнит-теста в подходящем случае?
Бек использовал юнит тестирование как пример TDD.
В этом случае, вам не составит труда процитировать, где Бек говорит, что ТДД — это нечто большое, чем юнит тесты, к которым еще потом были присобачены интеграционные тесты (являющиеся также юнит тестами по своей сути), ведь так?
чем поведенческое тестирование так сильно отличается от другого TDD? Почему нельзя BDD делать с помощью юнит-теста в подходящем случае?
Поведенческое тестирование проверяет какой-то спек, т.е. юзер стори, в котором может быть несколько участников, которые иногда еще и прямо не взаимодействуют. Оно тестирует поведение участка системы.
БДД — это философия тестирования поведения подсистемы, ТДД — философия тестирования маленького клочка, где количество тестов растет одновременно с коилчеством клочков.
Давайте так, и юнит тесты, и поведенческие тесты можно сделать и без либ вообще, ведь так? Вопросы именно в методологии создания теста, который один тест делает юнит тестом, а другой поведенческим.
На фреймворках юнит тестов можно сделать бдд, но они тогда перестанут быть юнит тестами, т.к. не будут соответствовать требованию о том, что тестируемый код не должен зависеть от другого тестируемого кода, нет? Более того, они не будут соответствовать глобальному требованию тдд о тестировании маленьких участков кода за раз.
Например, Мартин Фаулер martinfowler.com/...evelopment.html . Есть обратные пруфы более авторитетные чем ОБС?
А еще Фаулер внизу дает линки на книжки, статьи и т.п. Если почитать их, то станет ясно ,что описываюцца именно юнит тесты, хоть и прямо называюцца не всюду.
У меня пока сомнения, что непонимание у меня, т.к. вы нигде не дали четкого указания на то, что тдд — это нечто большее, чем юнит тесты и подразумевает под собой методологию поведенческого тестирования (примеры Фаулера как раз поведение не тестируют, как и линков, данных им самим в линке данном вами), которую вы пытаетесь мне впарить, как тдд, уж простите за грубость.
Итого
TDD — это плохо
А я ведь не шутил.
пруф в студию, т.к. подобного вашему утверждению нигде не встречал.
я ни у Бека, ни у Фаулера поведенческого тестирования не видел.
Ибо для меня ТДД кратно юнит-тестам стало именно после чтения Бека под зад лет назад.
Если почитать их, то станет ясно ,что описываюцца именно юнит тесты, хоть и прямо называюцца не всюду.
У меня пока сомнения, что непонимание у меня
даже и не знаю... Может википедия поможет? en.wikipedia.org/...ven_development :
behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD).
даже и не знаю... Может википедия поможет?
behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD).
ДАвайте я вам приведу аналогию, подобную вашей логике:
В свое время повозки на человеческой тяге с каменными колесами считались прогрессивным и удобным способом передвижения. На данный момент существуют автомобили, которые базируюцца на разработках повозок с каменными колесами на челвоеческой тяге. Вывод — автомобили — это повозки на челвоеческой тяге и имеют все те же недостатки.
ВЫ ощущаете некоторую нелогичность?
То, что что-то на чем-то основано не обозначает, что оно лучше, хуже или являецца тем же самым.
TDD — хорошо.
Это не идеал, но лучше чем вообще без тестов, как и пишут индусы.
если GDD — можно сразу на свалку и вообще тесты не писать.
Мне вот подумалось, что неплохо было бы коротенько рассказать историю возникновения подхода/методологии BDD. И я не стал себя останавливать.
Все началось с того, что у одного чела, Дэна Норта, не хватило фантазии ответить, входе своих тренингов по TDD, на один простой вопрос: а какие тесты мы должны вообще написать, чтобы было достаточно для покрытия функциональности?
И тут, к нему пришло прозрение: а давайте напишем в заголовках тестов, не что мы проверяем, а то, что мы ожидаем от работы еще не реализованной функциональности. Т.е. вместо того, чтобы заголовок теста звучал как: протестировать_что_sqrt_от_16_равно_4(), появились тесты:
должен_вычислять_квадратный_корень_для_положительных_чисел()
должен_вычислять_квадратный_корень_для_отрицательных_чисел()
и т.д.
Конечно же, и в этом случае, некоторых тестов может не хватать, но, теперь можно посмотреть в код тестов и выявить, какого кейса не хватает. Когда написано почти-человеческим языком, а не магией чисел — как-то читать легче.
Да, вы заметили, что заголовки теста теперь стали неким подобием спецификации/требованиями к классу или методу? Так оно и есть. И Бдышь! Так, около
Подобные идеи посещали головы людей и раньше, но, первым кто все описал, был Дэн Норт:
dannorth.net/...ntroducing-bdd
Кроме этой простой идеи с именами тестов, Дэн также описал то, что тесты написанные в таком духе, помогают и другим участникам команды лучше понимать функциональность, и в итоге, даже между собой разговаривать на «общепонятном языке» (ubiquitous language).
Если вы дочитали до этого места, и считаете, что ubiquitous language — это какая-то фигня. То, я прошу вас представить себе... собаку. Вот закройте глаза — и представьте себе собаку. Зачем? Узнаете в конце это поста этого текста. А можно, и сейчас пролистать.
В общем, наступил Дэн Норт своей статьей на мозоль проблемы взаимопонимания внутри команды. А заболела эта мозоль где-то за океаном, у Гойко Аджича ( gojko.net ), который этой проблемой всерьез и занимался. И тут-то он и написал книгу: Specification by Example (specificationbyexample.com). Которая как раз и подсказывает как достичь этого взаимопонимания, ubiquitous language, и не просто внутри команды, а внутри stackholder’ов, т.е. между заинтересованными лицами. Вот тестировщик, заинтересованное лицо? — Конечно, ведь он в команде работает и ЗП за это получает и хочет чтобы программисты написали успешный продукт. А программист? А заказчик/продуктовнер/продукт менеджер? — Ответ: Да. И настолько это была прикольная идея, спецификация через пример, что стала подмножеством BDD.
Дэн Норт и Гойко Аджич говорили еще об одной идеи. О том, что требования должны идти из потребностей бизнеса. Т.е., чтобы разработчики не фигачили всякую фигню, которая никогда никому и нужна не будет, а делали все для хорошего решения бизнес-задач вовремя. Учитывая то, что Дэн был больше человеком техническим, Гойко просто удалось эту идею лучше донести. Вот что означает этот «outside-in» в определении BDD.
Спускаясь с небес, давайте вернемся к инструментам. Наверное, это первое, что мы видим, и после чего, немногие из нас продолжают копать саму идею. Jasmine, Cucumber, BDDfy, Specflow и множество других... это... инструменты, которые помогают воплощать подходы BDD в жизнь.
Это не значит, что если вы возьмете молоток, то сразу же забьете гвоздь. Точно так же с BDD-инструментами. Они помогают работать людям, которые понимают теорию BDD. Но, вряд ли у вас получится что-то BDD-шное, только потому, что вы используете инструмент.
И вот вам еще один резкий поворот. Есть крылатая фраза «BDD is TDD done right». Которую многие понимают, как «BDD — это круто, а ваш TDD — фуфло». На самом же деле: BDD — это попытка сформулировать лучшие практики TDD. Т.е. BDD пересекается с TDD, предлагая хорошие практики решения некоторых проблем.
И вот еще резкий поворот. Статья от Дэна Норта о том, что BDD — это как TDD, но, если...
dannorth.net/...is-like-tdd-if
Я надеюсь, что мне удалось вас окончательно запутать, либо внести ясность.
----
* не знаю как вы, а я представил себе таксу. Я — тестировщик, и буду тестировать то, что вы напишите — как таксу. Если вы представили бульдога... нет, это не ваша проблема. Просто, мы говорим на разных языках, а не на... кхем... ubiquitous language
Добавлю:
Давайте задумаемся, где можно использовать BDD
Все очень просто. Ровно там, где можно описать, как должна себя вести система или отдельный метод. Т.е., практически везде.
Другое дело, как должны выглядит тесты.
Если вы реализуете модуль для подсчета скидок
Тогда, тесты должны быть написаны в более человеко-читабельной форме. Инструменты Conrordion, Fitnesse, Cucumber — не идеальны, но помогают писать тесты в такой форме.
Что если вы реализуете свой новый библиотечный контейнер MyList<t>?
Наверняка, всем, кроме программистов будет наплевать на детали. А те, для кого вы пишете MyList, с легкостью разберутся в ваших юнит-тестах без всякого выпендрежа с «As a system I want to have a MyList<t> in order to Add new elements»
У Буча есть на тему «собаки» отличная аналогия. Ветеринар думает о собаке как о пациенте, органы там, болячки, владелец собаки думает о ней как о друге, тапочки там принести и т.д., а продавец консервов, как об источнике прибыли, чем больше сожрет, тем лучше.
И это, что интересно, одна и та же собака!
„Плагиатю” Дмитрия:)
youtu.be/GEcpbOaS6Bw
www.slideshare.net/...h-bdd-automation-engineer
можно я по-простому?
есть мухи и котлеты.
<мухи> овнокод покрытый юнит тестами пахнет меньше. чем сильнее покрыт - тем меньше пахнет. Аутсорсинговое мышление: меньше вникай в бизнес-логику и не парься о судьбе продукта. Закостылил-покрыл тестами- втюхал- получил деньги за попочасы. </мухи>
<котлеты> Дизайн, документирование, рефакторинг. Понимание бизнес логики. Борьба с техническим долгом. Функциональные тесты со специальной БД для них. </котлеты>
каждому — своё.
Подскажите в какой компании есть котлеты? Я туда пойду как-нибудь, бо мухи уже запарили.
В целом очень метко, в яблочко!
котлеты — это процесс.
на них норовят слететься проворные мухи.
процесс- это борьба с мухами.
Получается с одной стороны на запах котлет слетаются мухи, с другой — их со скоростью света жрёт дядя Вася.
В итоге котлеты никто не видит.
Получается котлеты — миф о хорошей жизни для мух?
могу ответить только приблизительно: хрен его знает.
Микрософт. Г-г-г.
научите как описать тестами бизнес логику не вникая в нее.
Если бизнес-логика состоит из метода/-ов, в котором 500 одноуровневых if-ов, то можно и не вникать для написания Unit-тестов.
К тому же программист мыслит категориями модулей/пакетов/классов/методов/переменных, а не объектами из реальной жизни.
какие ифы вы о чем? у вас есть требования от заказчика, никаких методов и тем более ифов в них нет. откуда-то появляются тесты. откуда они появляются?
У вас есть уже написанная легаси-система, скорее всего она писалась по документации, но ее нет, тестов тоже нет. Есть метод, реализующий ВАЖНЕЙШУЮ операцию и в нем есть пицот if-ов, чтобы как-то модифицировать существующее «наследие», надо покрыть тестами и проверить как функционирует то, что есть => идем покрывать пицот if-ов тестами.
Если разработка с нуля, то:
1) в начале пишете тест он не компилится
2) дописываете код, теперь тест компилится, но не проходит
3) дописываете код МИНИМАЛЬНО, чтобы проходил
4) тест проходит — зеленая полоса. Цель — ее придерживаться
5) итерационно дописываем код маленькими шагами ОДНОВРЕМЕННО с обновлением своих тестов. Чтобы тесты покрывали ВСЕ выполнения кода
6) ????????
7) PROFIT
8) повторить нужное количество раз
P.S. почитайте на досуге TDD от Кент-а Бек-а:
www.ozon.ru/...ail/id/1501671
говорят, что молодым senior-ам может быть полезна.
Мда, всё и правда печально. Палю тему: слона надо есть по кусочку.
как описать тестами бизнес логику не вникая в нее.мухи окакивают тестами, этого достаточно в большинстве случаев.
клиенту в борделе аутсорсинга трудно рассчитывать на любовьВ нетленки.
Юнит-тесты не кроют бизнес логику.
— Скажите, любезный, где мы находимся?
— На воздушном шаре.
— Какой абсолютно правильный и абсолютно бесполезный ответ. Программист, видимо.
(к)
Хотя технически это и реализуемо, но формального решения «сделай раз, сделай два — профит!» — нет.
ЗЫ: пусть бы хоть техническую реализацию тестами покрывали — смотреть стыдно на «а-ля код из-под
не до конца понимаю суть претензии.
Если
Вполне возможно, что эти 8 пунктов — ацтой, тогда что вы предлагаете?
<котлеты>
....
Функциональные тесты со специальной БД для них.
зачем? БД в смысле для чего
Regression testing -же.
Ручками оно конечно можно, но не всегда есть в достаточном количестве ручки к которым есть доверие.
А надо-ть быстро.
А система life-critical.
Fuckup стОит больших денег.
а, то есть копия БД для прогона тестов. Тестовая среда. То понятно. Думал своя БД для именно тестовой инфраструктуры.
Еще возможна конфигурация, когда создается тестовая БД по оригинальной сразу в память и на ней прогоняются тесты наподобие DBUnit, единственный минус — кучу памяти жрет.
Решает проблемы тестирования на реальной БД, заключающиеся в низкой производительности дисковых операций, всякие lock-и, журналы и прочее, а также чтоб случайно не грохнуть реальные данные.
Если взамодействие с БД полностью через ORM, например Hibernate, то можно запросто тестировать на Postgres-е, имея на продакшене Oracle, как я и делаю.
BDD asks questions about behavior of app before and during development to reduce miscommunication.
BDD concentrates on behavior of app vs. implementation of app.
Idea (BDD): user story can be formulated as acceptance test before code is written.
Test Driven Design or TDD tests implementation.
** выше — цитаты из курса SaaS на coursera.
— BDD:
Слово Driven в BDD означает, что behaviour (выраженные в виде user stories) ведут вашу разработку. И вы разрабатываете именно те фичи, которые нужны заказчику.
В итоге одной user story соответствует Acceptance test.
Т.е. сначала пишете список user stories, потом их реализуете, показываете заказчику, потом берете следующие user stories и их реализуете, показываете и т.д..
Это тесно связано с методологией Agile Development.
— TDD
Ключевое слово Driven в TDD означает, что сначала пишется тест (который задает, что должно быть и как должна работать система), а потом уже пишется код.
Т.е. TDD — это не набор определенных тестов, это — методология (стиль) процесса разработки.
Точно так же BDD — это не набор определенных тестов, это идея процесса разработки, часть которого — написание тестов.
Если вы вначале пишете весь код, а потом перед сдачей проекта пишет набор тестов (которые могут и не покрыть все 100% кода) — то это не TDD.
— Процесс разработки
Если вы узнали требования от заказчика или прочитав спецификацию, и начали создание системы с написания кода (классов, сервисов, структуры базы данных).
Потом вы пообщались с заказчиком, уточнили требования, или поменялась спецификация, и после этого вы поменяли свой код.
И тут пришло время сдавать проект и вы решили писать тесты...
То это не имеет никакого отношения к TDD и BDD.
ну БДД — это как бы формализация самих тестов. что стоит тестировать, чтобы повысить значимость для бизнеса.
то-есть бизнес интересует поведение системы — значит и автоматизировать и надо проверку поведения системы.
Разница (если можно вообще о ней говорить, т.к. БДД подмножество ТДД), по-моему, проста: в «обычном» ТДД тестируется, как правило, состояние системы после каких-то действий — жамкнули на кнопочку — проверили что в базу записалось. В БДД же тестируется прежде всего поведение, с системой общаемся как чёрным ящиком (как обычный юзер :), по пользовательским сценариям, где отсутствуют такие термины как, например, БД.
ну вот чаще всего тдд ассоциируется с написанием юнит тестов до написания логики. а юнит тесты проверяют поведение модуля (функции) и естественно никто не проверяет, что в следствии нажатия на кнопку что-то записалось в базу данных. такое проверять юнит тестами точно не будут.
юнит тестами проверяют что функция вернула или как себя повела получив что-то на вход.
Очень часто в TDD тестируется именно состояние. Создали объект (или глобальную переменную :), установили состояние, дёрнули метод (вызвали не чистую функцию), проверили, что состояние изменилось нужным образом. Да, проверку изменения состояния можно считать проверкой поведения, но это очень частный случай, по-моему.
value таких тестов нулевое.
кроме того у вас вряд ли получится написать такой тест до имплементации
кроме того у вас вряд ли получится написать такой тест до имплементацииВ 90% случаев можно написать с PowerMock-ом.
ИМХО от модульных и JUnit (xUnit) тестов есть польза только в случае, если они написаны ДО реализации.
Если после — и в методе юзается: (что-то одно или все сразу)
1) мощная статика,
2) new
3) многократно вложенные циклы
4) метки
5) длинный спагетти-код и if-ы вложенности больше
то даже если есть на него тест, то маловероятно, что он будет покрывать все варианты выполнения метода (написание пост-фактум) и будет только «для галочки»
только в случае, если они написаны ДО реализации.Совершенно без разницы — одно другому не противоречит. ООП дает инструмент многократного заворачивания черного ящика в свои собственные велосипеды, которые в свою очередь становятся черными ящиками по наследству. Большинство
Что же касается стремления не писать тесты до того как — это связано в первую очередь с невозможностью осознания и сколь бы то ни было формализации того, что вообще пишется и должно быть написано. Причем на уровне product owner описание acceptance criteria встречаются такие, что приходится подгонять под них тесты, ибо спорить — себе дороже. При этом еще и все же анализировать, что же именно таки нужно сделать. Здесь уже сторонний анализ бизнеса заказчика вне системы отношений подрядчика начинает играть весомую роль, но это уже совсем другая история.
Мораль: лучше хоть какие-то формальные тесты, чем вообще никаких.
Мораль: лучше хоть какие-то формальные тесты, чем вообще никаких.Нет, категорически не согласен.
ИМХО тесты должны быть до кода, по TDD, либо их вообще не должно быть.
Вообще тесты предполагают что тестируемый объект рассматривается как черный ящик. Причем именно на тестах внешнего взаимодействия чаще всего и видны как особенности реализации вроде «костылей» (классическое: магические числа), так и отсутствие части реализации как таковой. Ничего плохого в написании тестов пост-фактум нет — реальность сурова и тестируемый модуль может разрабатываться и вовсе не нами, а интегрировать его — таки нам и с нас таки спросят. Плюс в таком случае тесты служат великолепной и, видимо, идеальной отправной точкой для начала дискуссии с разработчиками модуля на предмет понимания и доделок/недоделок/багов вообще. Если уж на то пошло, то тест пожалуй таки лучше документации — при условии что то и другое хорошо и внятно написано. Ведь именно документация может не соответствовать, а тесту несоотв. трудно — ведь это будет выявлено не отходя от кассы. И даже более того: документация может и остаться «пониманием того как должно было быть», в то время как тест, независимо от времени его написание — существо уже сугубо более объективное. Понятно, что в случае TDD сама суть «driven» предполагает написание тестов до того как. Но непреложные истины — штука странная. Если тестов нет — пусть лучше они станут быть, чем уверовать: их не может быть, потому как их и не было сперва.
Как-то так.
вы спутали интеграционные и функциональные тесты, которые видят систему/фичу как черный ящик. Т.е. допустим вы подаете на вход «1», внутри 1 млн строк кода и ждете на выходе «2».
модульные = xUnit тесты тестируют код как белый ящик. Т.е. вам надо этот миллион строк кода покрыть.
Разумеется интеграционные/функциональные тесты пишутся после. Но после каждой фичи. А не после того как прилетит бааааальшой факап.
Scope проверки юнит тестов намного меньше функциональных тестов. Юнит тест проверяет маленький кусочек кода. Функциональный тест проверяет кусок фичи.
Работающие юнит тесты ничего не говорят о работающем продукте. Но дают большую надежду
Scope проверки юнит тестов намного меньше функциональных тестов.Круто, кэп. От только ТДД не требует написания только «юнит-тестов на моках», можно работать по ТДД, а не по БДД, но при этом иметь и интеграционные, и функциональные и даже тесты контракта.
Привет мичман, я не удивлю тебя если скажу, что можно работать и ТДД и БДД одновременно. А где я сделал исключение одного из другого в предыдущем комментарии?
А где я сделал исключение одного из другого в предыдущем комментарии?Если вы не сопоставляете функциональные тесты с БДД, а юнит-тесты с ТДД, то зачем был ваш коммент в теме «TDD vs BDD. В чем разница?»?
ссылки на описание давно уже нагуглил. А вот как на практике понять — есть проект, есть набор тестов, Когда можно сказать что проект был сделан по ТДД или все-таки это БДД?
TDD — если при изменении значимой строчки кода хоть один тест упадет. Или еще каноничнее — каждая значимая строка кода была добавлена для того, чтобы починить падающий тест.
BDD — это уже стиль написания самих тестов. Сказать что проект был сделан по BDD можно когда фичи имплементились начаная с падающего теста описанного в стиле BDD.
Кто-то может обьяснить разницу между TDD и BDD?Никто :)
TDD vs BDD. В чем разница?Минорная разница (но многие считают ее очень важной):
Ну немного акцентируют внимание на более разумном выборе тестов. Но это же не причина еще один 3 буквенный базворд придумывать.Причина :) А есть еще и
TDD — делать вещи правильно. BDD — делать правильные вещи. Они не взаимозаменяемы.
это философия, вопрос пракчический — разрабатываем прогу, есть спека, есть тесты проверяющие что прога работает в соответсвие со спекой , тесты прошли — значит мы правило сделали правильные вещи :) Но такое используется и без заявлений «у нас BDD»
Если вас интересует практика, то рекомендую начать с вот этой книги
it-ebooks.info/book/675
В этой книге написано как выиграть на Форексе? Если да, то зачем выигрывать, если нет, то зачем её читать?
Евгений Ваганыч? Простите, не узнал, богатым будете, даже без форекса.
Читать книгу надо для того чтобы:
1) Понять что такое БДД
2) Разобраться с кукумбером / геркином
3) Узнать что такое файл описания фичей и как его едят
4) Научиться преобразовывать описание фичи в тест
Я бы сказал, что файлы с описанием фич очень полезная штука, даже если никакого БДД не планируется вообще.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Нет, не одно и тоже.
Тест-дривен (en.wikipedia.org/...ven_development) и бихейвер-дривен (en.wikipedia.org/...ven_development ), хоть BDD это «вариация на тему» TDD.
Почитайте ссылки на википедию, уверен что всё всё прояснится (кстати, нагуглить и сами могли бы).
ссылки на описание давно уже нагуглил. А вот как на практике понять — есть проект, есть набор тестов, Когда можно сказать что проект был сделан по ТДД или все-таки это БДД?
Если проект уже сделан, то узнать как он писался (вторая буква D — driven) не возможно без тех, кто его делал. Вопрос скорее всего о unit testing и functional testing.
— TDD (see en.wikipedia.org/...en_development
TDD is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming
Это означает:
— TDD — это процесс разработки, а не набор тестов.
— сначала пишутся тесты, а потом пишется код (минимальный кусок кода, который делает тест успешным).
— BDD (see en.wikipedia.org/...en_development
BDD is a software development process based on test-driven development (TDD).
Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development, with the aim of delivering “software that matters”.
Тут важно, что в процесс разработки вовлечены бизнес аналитики и другие люди (не разработчики), которые воспринимают проект на очень “высоком” уровне, и они выражают свои требования к системе, которые описываются в виде customer-understandable user stories.
Технически это можно выразить в виде integration tests и acceptance tests (их не должно быть много).
Существуют технические средства, которые позволяют формулировать тесты (описыващие user stories) без знаний программирования.
BDD — Blog Driven Development?
Если да, то разница между TDD и BDD — просто огромная.
Да, Сергей. Собственно первый абзац по вашей ссылке и есть ответ на вопрос ТС.
In software engineering, behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD).[1][2] Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development,[1][3] with the aim of delivering “software that matters”.[4]
звучит как очередная маркетинговая хрень.
mbines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and designА вопрос сугубо практический. Как понять что у нас уже не TDD, а проект перешагнул какую-то незримую границу и наступило полное BDD?
А как понять что у вас уже Agile/Scrum? :)
Если работает, то это Agile/Scrum, а если не работает — всего лишь «очередная маркетинговая хрень».
C TDD, BDD, DDD и прочими xDD то же самое.
Не так, если на Форексе выигрывает, тогда
Agile/Scrum
Dmytro Zharii
Настасий Петрович
anonymous
Roman Roman
Sergii Motynga
Roman Brunets
Mr Grinch
Kyrylo Perevozchykov
Дмитрий Мирошник
Roman Brunets
trimm
Alex Fogol
trimm
Mykola Gurov
Gabriel Angelos
Dmytro Zharii
Kostiantyn Kudriavtsev
Iakiv Kramarenko
Gremlin
Gremlin
Dmytro Riabov
Dmytro Titov
Roman Beslik
Max I
Dmytro Riabov
Владимир Чернышев
Владимир Чернышев
Eugen Martynov
Bogdan Shyiak
Eugen Martynov
Mykola Gurov
Bogdan Shyiak
anonymous
Андрей Иванов
Alexander Kuznyak
Max I
Gabriel Angelos
Sergii Voloshyn
Alexander Kuznyak
Найкращі коментарі пропустити