TDD/BDD в чем разница и для каких видов модулей стоит использовать?

Question

[Sarkis Arutiunian]

Всем привет, я только начинаю изучение систем автоматизированного тестирования, остановился на mocha + chai + sinon. В целом логика работы и построение тест-кейсов понятны.
Но есть несколько вопросов на которые хотелось бы услышать ответ от знающих людей.

1. в чем разница между TDD и BDD когда что лучше использовать? (к примеру у mocha есть отдельные настройки для bdd и tdd).
2. такой вид тестирования актуален только для функциональных частей модулей? или для UI то же?
К примеру я работаю с Meteor + React и 90% модулей это react компоненты которые могут включать в себя некоторые функции-обработчики, и очень редко дополнительные вспомогательные функции. Так вот вопрос что тестировать? нужно ли тестировать обработчики? нужно ли тестировать коректность вывода компанента в DOM (хотя не представляю как это делать)? или стоить тестировать только дополнительный функционал сайта не имеющий отнашения к UI?
3. ну и то же хотелось бы знать, какие виды модулей тестировать, только содержащие функционал, или модули включающей UI компоненты и оброботчики, то же?

Заранее спасибо за ответы!
За ссылки на доп. литературу отдельное спасибо и плюс)

Answer 1

[sim3x]

Видов тестов много
https://events.yandex.ru/lib/talks/535/

*DD - стиль разработки, когда ты сначала пишешь тест, потом он проваливается, потом ты пишешь код, чтоб тест прошел

B или T использовать решать или тебе, или начальству. Лучше попробовать писать одно и тоже на обоих и уже исходя из своего опыта выбрать

BDD - лучше подходит для функциональных тестов
ТDD - для юнит

для функциональных частей модулей

оксюморон. Все что ты пишешь выполняет каку-то функцию

Тестировать модуль, если он будет переиспользован, - стоит

бизнесс критикал вещи тестировать обязательно

нужно ли тестировать обработчики?

https://facebook.github.io/react/docs/test-utils.html

нужно ли тестировать коректность вывода компанента в DOM (хотя не представляю как это делать)?

такое проще оставить ручному тестированию

или стоить тестировать только дополнительный функционал сайта не имеющий отношения к UI?

такой функционал уже должен быть покрыт юнит тестами и функциональными тестами и должен показать ошибку не доходя до UI

Answer 2

[Сергей Протько]

TDD

- пишем тесты - маленький кусочек, то что можно минут за 10 написать. На этом этапе мы формулируем что мы хотим написать.
- пишем код - пишем код, который делает тесты "зелеными". то есть все работает. Мы делаем это максимально быстро, самым тупым способом, который просто быстрее всего сделать.
- рефакторинг - после того как все работает, или еще через пару итераций, что бы набралось чуть больше "грязи", чистим код поочередно. Важно при рефакторинге чистить что-то одно. Либо код, либо тесты (да да, их тоже надо рефакторить иногда устраняя дублирование). Поправили код - прогнали тесты, все хорошо? тогда можно тесты подправить. Ну и т.д.

BDD
- пишем фичаспеки - это этап детализации более высокоуровневых требований. Фич. Обычно на этом этапе просто записываются мысли как что должно работать. В этом плане описание фичи описывает юзкейс, а сценарии - детализируют поведение фичи. То есть если у кого-то возникает вопрос как что должно работать, люди описывают пример в виде сценария. Типа что есть, что мы делаем и что в итоге должна выдать система.
- пишем код - так же как и в случае с tdd, можно писать код для разных уровней.
- рефакторинг.

TDD - для одного разработчика, BDD - для команды. А BDD-style assertions для chai - это пафос. По сути это "планирование фич" в рамках библиотек и отдельных объектов. Чуть меньший масштаб. Но ничем от TDD вообще не отличается, хотя если сильно постараться можно так же оценивать ценность фич для пользователей нашей библиотеки и т.д.

Как никак в BDD основная мысль - фичаспеки должен иметь возможность читать продукт оунер или стэкхолдеры, то есть те кому проект собственно нужен, что бы говорить должно работать так или нет. В случае с библиотеками... ну вы пишите что-то для девелоперов, а они в состоянии читать тесты как фичаспеку. И в принципе от предметной области недалеко.

Comments

[Sarkis Arutiunian]

Спасибо за подробный ответ!

Answer 3

[Андрей Белокопытов]

Очень советую вот эту книгу для понимания концепции BDD - BDD in action. Написана достаточно простым для восприятия языком, основные идеи можно понять из 1-й главы.