Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Люди довольно серьезно настроены в отношении BDD. Я часто слышу, скажем, такие мнения:

"Зачем мне использовать BDD-фреймворк вместо традиционного – например, JUnit, NUnit, pytest? Дополнительный уровень шагов Gherkin мешает коду автоматизации, и вместо него я могу напрямую писать код для этих шагов. BDD-фреймворки требуют кучу лишней работы, а толку от этого никакого. Моя команда все равно не пользуется практиками разработки через реализацию поведения".

Я могу понять эти мнения, особенно в исполнении тех, кто участвовал в проекте с плохими BDD-практиками. Даже если команда не использует их во всей полноте, я все равно уверен, что BDD-фреймворки тест-автоматизации лучше, нежели традиционные, для большей части тестирования характеристик (на уровне выше юнит-тестов, для черного ящика). И вот почему.

Разделение тест-кейсов и кода тестов

Тест-кейсы и код тестов – разные сущности. У меня должна быть возможность проектировать, обсуждать и оценивать тест-кейс, даже не дотрагиваясь до кода. Мы описываем фичи открытым текстом, и точно также мы должны описывать тесты. Определения шагов – это не что иное, как автоматизация шагов тест-кейса. Традиционные фреймворки не разделяют эти понятия, даже если тест-методы перегружены комментариями.

Направляющие рельсы

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

Встроенная возможность переиспользования

Шаги – это кирпичики тест-кейсов, и шаги в тест-кейсах почти всегда повторяются. Фреймворки BDD относятся к шагу, как к отдельной уникальной сущности. Шаг вместе с определением можно использовать в любом сценарии. Шаги также можно параметризовать для большей гибкости. Это создает эффект лавины, когда все шаги проработаны: для новых тестов может вообще не требоваться новый код! У традиционных фреймворков просто-напросто отсутствует подобный механизм. Его можно внедрить, вызывая функции и классы вне тест-классов, но не все автоматизаторы достаточно дисциплинированы для этого, и каждый будет делать это по-своему.

Аспектно-ориентированное управление

Хорошие фреймворки автоматически управляются со сквозной функциональностью. Логирование, внедрение зависимостей и очистка не должны мешать тест-кейсам. Фреймворки BDD дают возможность для вставки дополнительной логики для подобной функциональности, обходящей шаги, сценарии, фичи, и даже набор тестов целиком. Эти методы могут втиснуться в шаги, потому что фреймворк структурирован вокруг шагов. К примеру, перехватчики могут автоматически логировать шаги в Extent Reports, а не заставлять программистов писать явные вызовы логирования в каждом тест-методе.

Легкое ревью

Ничто не портит вам день так, как нечитабельное код-ревью по фичам, с которыми вы не знакомы. Вы должны дать полезную обратную связь, но за то короткое время, которое у вас есть на ознакомление, вы не можете разобраться, что там вообще происходит. Хороший Gherkin сильно упрощает этот процесс. Ревьюер может оценить тест-кейс отдельно от кода, чтобы убедиться, что кейс сам по себе хорош. На этом уровне ревью может проводить даже далекий от технической стороны вопроса человек – например, продакт-оунер. Затем ревьюер может отправить кейс назад с замечаниями, или, если кейс достаточно хорош, зарыться глубже в код автоматизации.

Простое внедрение

Адаптировать новых коллег к инструменту может быть непростой задачей. Им нужно многое узнать о продукте, коде и практиках команды. Если тесты написаны с использованием фреймворка BDD, новички могут изучать продукт, просто читая спецификации поведения. Новые автоматизаторы аналогичным образом могут полагаться на существующие шаги как для повторного использования, так и в качестве образца для разработки новых тестов.

Другие причины

Я уверен, что у BDD-фреймворков есть и другие преимущества, но эти, с моей точки зрения, важнее всего. Я пристрастен, поэтому буду рад выслушать ваши мнения!

Обсудить в форуме