Задать вопрос

У кого из вас есть TDD или BDD в разработке, что конкретно вы делаете, когда, как к этому пришли?

Читаю "Гибкое тестирование", Xunit patterns, интересно, а кто и как это у себя применяет, пытался применять, стал применять, перестал применять и прочие подробности.
  • Вопрос задан
  • 1951 просмотр
Подписаться 16 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 3
nonlux
@nonlux
Книгу не читал, по этому аналогий привести не смогу
Пишу на php для веб c bdd

1. Пишу bdd story.
( в моем случае это сценарии behat)
Для меня bdd story это как функциональные и интеграционные тесты, в которых я проверяю работу всего моего продукта в целом.

Тут вынес несколько правил для себя:
1.1. Обязательно формулировать цель (название) сценария
- Я вхожу в личный кабинет
- Я создаю новую статью блога
Это поможет отстраниться от лишнего и не превратить сценарий в кашу

1.2. Писать на нативном языке без технических подробностей
Я поначалу долго сопротивлялся писать, что либо кроме файлов трансляции на русском. Но потом вкурил фишку. По сути сценарии у меня превратились не просто в тесты, а мини todo list. Всегда четкий и понятный.
А избегание технических подробностей помогает забыть о проектирование архитектуры системы на этапе написания сценария.
И мне гораздо понятнее:
- Я должен видеть "Отказано в доступе"
чем
- Статус код страницы должен быть 403

1.3. Я(Исполнитель) сценария дурак )
Сценарий не должен быть замудреным. От должен быть простой и не держать какие-либо данные "в голове".

-
2. Далее я начинаю реализовывать шаги сценария
(писать тесты)
- Если я имею на руках желтый (не реализованный) сценарий, то начинаю уже задумываться о технических подробностях которые лежат на поверхности:
Например (приведенный код это псевдокод для понятности

Я должен быть на странице "Новости"
assert( $uri, '/news');

Я вижу заголовок статьи "Эта прекрасная статья"
assertTextInElement('#newsTitle", $title);

- Если я имею на руках красный тест, то пришло время для кода..

3. Написание практически всего кода предшествует у меня BDDSpec
(в моем случае phpspec)

И так, я получил ошибку от bahat. Я специально настроил утилиту так что бы она ругалась ошибками разрабатываемой системы.
В итоге я получаю такую ошибку:
- uri '/new' not exist

Это для меня прямое указание к действию. т.е я должен создать новую страницу.
В рамках моей системы уже существуют правила:
- новая страница - это новое action у контролера.
- action должен вернуть массив значений для шаблона
Опираясь на это я создаю спецификацию для контроллера
class ControllerSpec  {
  public function it_should_show_news ()
  {
    $this->newsAction()->shouldBeArray();
  }
}


И далее код, который пройдет этот тест:
class Controller {
  public function newsAction() 
  {
     return [];
  }
}


4. После этого запустив phpspec я получил зеленый bddspec
5. После этого cнова возвращаюсь к bddstory
Получаю зеленый шаг
6. Возвращаюсь на шаг 2.

Так начинает расти система и обрастать новым протестированным функционалом.

До bdd использовал tdd c PHPUnit и был очень доволен, пока не подсел на behat + phpspec
Ответ написан
@tdurova Автор вопроса
Сегодня узнала, что в одной команде функциональные тесты на фронтенд пишут до реализации фич на Selenium, немного в шоке..
Ответ написан
samizdam
@samizdam
Книгу не читал. В последних проектах использую TDD. Стек: Yii1/2 (backend) + AngularJS (frontend) = REST. Для тестирования API нравиться Codeception - BDD testing framework для (на) php.

Конкретно делаю следующее:
1. Беру задачу на новый метод / ресурс / поле в API
2. Пишу тест, проверяющий требуемый функционал: выполнение HTTP-запроса и проверка статус кодов на разных кейсах (401 / 403 / 404 / 200 etc), или проверка наличия поля и значения
3. Запускаю тест - убеждаюсь что проваливается - ничего не поделаешь, надо значит кодить =)
4. Пилю код пока все ассерты не позеленеют.
5. Если необходимо провожу рефакторинг.
6. Обновляю CHANGELOG, коммичу, ставлю тег, пул реквест.
7. Закрываю задачу, пингую фронтенд.

(Дополнительный гол - к прогону тестов прикручен велосипед который генерирует документацию. В двух словах - на каждый запрос-ответ в момент прогона тестов появляется html с дампом объектов запрос и ответа - таким образом API обладает самообновляющейся документацией. )

Надо аналитиков / менеджеров (или кто у вас отвечает за требования) настраивать на поставку требований в виде максимально приближённом к тест-кейсам. В сферическом BDD в вакууме заказчик может формулировать требования в виде готовым к употреблению системой тестирования: Gherkin. Сам не использовал, но коллега отзывался что вполне себе рабочий инструмент.

Как пришёл, сейчас уже сложно сложно сказать. Фаулер присоветовал, или Бек =)
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы
22 дек. 2024, в 14:07
15000 руб./за проект
22 дек. 2024, в 13:01
50000 руб./за проект
22 дек. 2024, в 10:44
15000 руб./за проект