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

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

❓В чем разница

  • TDD хорошо подходит для юнит-тестирования, т.е. для проверки работы отдельных модулей самих по себе. BDD — для интеграционного (т.е. для проверки, как отдельные модули работают друг с другом) и e2e (т.е. для проверки всей системы целиком) тестирования.
  • TDD: тесты сразу реализуются в коде, для BDD чаще всего описываются шаги на языке, понятном всем, а не только разработчикам.
  • TDD: юнит-тесты пишут сами разработчики. BDD требует объедения усилий разных членов команды. Обычно тест-кейсы (шаги) описываются ручным тестировщиком или аналитиком и воплощаются в код тестировщиком-автоматизатором. В нашей команде мы (фронтенедеры) описываем шаги вместе с тестировщиками, а код тестов пишет фронтенд-команда.
  • TDD проверяет работу функций, BDD — пользовательские сценарии.

❓А как выглядит на примере

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

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

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

--

--

--

Frontend developer at Mail.Ru Group 👩‍💻, leader of moscowcss community, conference speaker 🎤, write about IT, channel: t.me/frontend_thoughts

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Liudmila Mzhachikh

Liudmila Mzhachikh

Frontend developer at Mail.Ru Group 👩‍💻, leader of moscowcss community, conference speaker 🎤, write about IT, channel: t.me/frontend_thoughts

More from Medium

Simple Motivational Rules

Motivation

The Three Wise Monkeys

Reset Phase Week 4 — It’s all about science

The One Thing All Creatives Need

a guy smoking a cigarette leaning on a lightbox with the text “this party sucks”