Задать вопрос
sarkis-tlt
@sarkis-tlt
Full Stack Web Developer (ReactJS/MeteorJS/NodeJS)
javascript

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

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

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

Заранее спасибо за ответы!
За ссылки на доп. литературу отдельное спасибо и плюс)
  • Вопрос задан
  • 10464 просмотра
Комментировать
Подписаться 5 Оценить Комментировать
Решения вопроса 1
sim3x
@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
Ответ написан
Комментировать
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
TDD

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
JavaScript разработчик
SummerWeb • Ярославль
от 100 000 до 140 000 ₽
JavaScript разработчик
вАйТи
от 5 000 до 25 000 ₽
JavaScript Fullstack
OnClass
от 200 000 до 600 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Сверстать 3 страницы для WebApp и 1 Web
25 апр. 2024, в 13:36
2000 руб./за проект
Интегрировать в flutter проект storekit external link (ios)
25 апр. 2024, в 13:21
5000 руб./за проект
Реализовать часть интерфейса для образовательных курсов на React
25 апр. 2024, в 13:13
5000 руб./за проект
Ещё заказы