Что такое TDD и BDD и что должен знать о них фронтендер
Что это вообще за буквы
И то, и другое — подходы к разработке, когда сначала пишутся тесты, а потом код.
*DD (*что-то* Driven Development) — разработка, основанная на чем-то.
TDD (Test Driven Development) — Разработка на основе тестов.
BDD (Behavior Driven Development) — Разработка на основе поведения.
BDD, на самом деле, является расширением TDD-подхода. Тем не менее, они предназначены для разных целей и для их реализации используются разные инструменты. В разных командах эти понятия могут интерпретировать по-разному, и часто возникает путаница между ними.
В чем разница
- TDD хорошо подходит для юнит-тестирования, т.е. для проверки работы отдельных модулей самих по себе. BDD — для интеграционного (т.е. для проверки, как отдельные модули работают друг с другом) и e2e (т.е. для проверки всей системы целиком) тестирования.
- TDD: тесты сразу реализуются в коде, для BDD чаще всего описываются шаги на языке, понятном всем, а не только разработчикам.
- TDD: юнит-тесты пишут сами разработчики. BDD требует объедения усилий разных членов команды. Обычно тест-кейсы (шаги) описываются ручным тестировщиком или аналитиком и воплощаются в код тестировщиком-автоматизатором. В нашей команде мы (фронтенедеры) описываем шаги вместе с тестировщиками, а код тестов пишет фронтенд-команда.
- TDD проверяет работу функций, BDD — пользовательские сценарии.
А как выглядит на примере
Давайте возьмем простую задачку. Нам нужно сделать форму, в которую мы вводим возраст котика и его вес, а в ответ получаем, сколько корма котик должен кушать в сутки.
Как подойти к этой задаче, используя TDD подход:
- Пишем тест, в котором проверяем, что функция getCatFood() возвращает нужные значения в разных ситуациях
- Проверяем, что тесты упали (кода еще нет)
- Пишем код функции очень просто — так чтобы тесты прошли
- Проверяем, что тесты прошли
- На этом шаге можем задуматься о качестве кода. Можем спокойно рефакторить и изменять код как угодно, т.к. у нас есть тесты, которые с уверенностью скажут, что мы где-то ошиблись
- Повторяем все вышеуказанные шаги еще раз
Как подойти к этой задаче, используя BDD подход:
- Процесс начинается с того что пользователь открывает форму
- Нам нужно протестировать числа которые выдает форма
- Нам нужно ввести 10–20 разных значений
- Проверка в данном случае это нажатие на Submit кнопку и проверка значения
- Тест пройдет если результат на форме соответствует “правильным” значениям
Далее мы это описываем с помощью специального синтаксиса (он зависит от инструмента, который используем, но суть одна). Например:
Функция: Расчет количества корма
Сценарий: При вводе валидных параметров отображается правильный ответ
Когда я нахожусь на странице с формой
И ввожу возраст 5 лет
И ввожу вес 5 кг
То мне отображается количество корма 500 г
Потом эти шаги реализуются в коде.
Я фронтендер, зачем мне это надо
Умение тестировать свой код — очень жирный плюс для фронтендера, и вот почему:
- ты продумываешь детали еще до реализации, это помогает абстрагироваться от кода и уловить непонятные моменты в ТЗ на самом раннем этапе
- помогают наладить коммуникацию между разными членами команды: разработчиком, тестировщиком, менеджером и тд.
- раньше отлавливаются ошибки в коде, а чем раньше поймана бага, тем дешевле ее пофиксить
- меньше переходов туда-обратно таска от разработчика к тестировщику, значит, таски быстрее доедут до прода и меньше придется переключаться между тасками
- разгружаете своих ручных тестировщиков. Регрессионное тестирование — процесс очень трудоемкий. Если все покрыто автотестами, им достаточно просто описать тест-кейсы, код могут написать автоматизатор или разработчик
- можно смелее делать рефакторинг
- хорошие тесты — это еще и документация, и они помогают быстрее адаптироваться новым членам команды
