Что такое TDD и BDD и что должен знать о них фронтендер

0
282

Что такое TDD и BDD и что должен знать о них фронтендер

Что это вообще за буквы

Что такое TDD и BDD и что должен знать о них фронтендер
Что такое 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 подход:

  1. Пишем тест, в котором проверяем, что функция getCatFood() возвращает нужные значения в разных ситуациях
  2. Проверяем, что тесты упали (кода еще нет)
  3. Пишем код функции очень просто — так чтобы тесты прошли
  4. Проверяем, что тесты прошли
  5. На этом шаге можем задуматься о качестве кода. Можем спокойно рефакторить и изменять код как угодно, т.к. у нас есть тесты, которые с уверенностью скажут, что мы где-то ошиблись
  6. Повторяем все вышеуказанные шаги еще раз

Как подойти к этой задаче, используя BDD подход:

  1. Процесс начинается с того что пользователь открывает форму
  2. Нам нужно протестировать числа которые выдает форма
  3. Нам нужно ввести 10–20 разных значений
  4. Проверка в данном случае это нажатие на Submit кнопку и проверка значения
  5. Тест пройдет если результат на форме соответствует “правильным” значениям

Далее мы это описываем с помощью специального синтаксиса (он зависит от инструмента, который используем, но суть одна). Например:

Функция: Расчет количества корма

Сценарий: При вводе валидных параметров отображается правильный ответ

Когда я нахожусь на странице с формой

И ввожу возраст 5 лет

И ввожу вес 5 кг

То мне отображается количество корма 500 г

Потом эти шаги реализуются в коде.

Я фронтендер, зачем мне это надо

Умение тестировать свой код — очень жирный плюс для фронтендера, и вот почему:

  • ты продумываешь детали еще до реализации, это помогает абстрагироваться от кода и уловить непонятные моменты в ТЗ на самом раннем этапе
  • помогают наладить коммуникацию между разными членами команды: разработчиком, тестировщиком, менеджером и тд.
  • раньше отлавливаются ошибки в коде, а чем раньше поймана бага, тем дешевле ее пофиксить
  • меньше переходов туда-обратно таска от разработчика к тестировщику, значит, таски быстрее доедут до прода и меньше придется переключаться между тасками
  • разгружаете своих ручных тестировщиков. Регрессионное тестирование — процесс очень трудоемкий. Если все покрыто автотестами, им достаточно просто описать тест-кейсы, код могут написать автоматизатор или разработчик
  • можно смелее делать рефакторинг
  • хорошие тесты — это еще и документация, и они помогают быстрее адаптироваться новым членам команды

источник