Home

Автор: Баз Дейкстра (Bas Dijkstra).
Оригинал статьи
Перевод: Ольга Алифанова 

BDD как техника существует много лет, но ее до сих пор понимают неправильно. В статье я хочу обсудить и развенчать два таких заблуждения.

Заблуждение №1: есть один-единственный правильный подход к BDD

Нет, это не так. Я верю, что существует некий «традиционный» процесс BDD, и мы следуем ему в ходе курса, но это не значит, что вам везде и всюду нужно следовать этому процессу побуквенно. Ровно наоборот! Как и ряд других методологий, BDD применима различными способами, в зависимости от структуры вашей компании и команды, опыта работы с BDD, совокупным командным навыкам, и т. п.

Мне нравится представлять BDD, как набор инструментов, из которого мы берем то, что нам, в нашем конкретном контексте, сейчас необходимо, и оставляем то, что не требуется. Попытка тщательно следовать традиционному процессу может для вас сработать, но с шансами будет ощущаться чем-то неестественным, навязанным, и «просто каким-то не таким». Это вполне понятно – все команды и контексты уникальны. Поэтому смело экспериментируйте с тем, что работает и что нет, не бойтесь отбрасывать нерабочее. Экспериментируйте, обучайтесь и подстраивайтесь, пока не найдете способ применения BDD, который подходит именно вам.

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

• Добиться единодушия, что именно должна делать создаваемая вами функция,
• Получить информацию об ожидаемом поведении с разных позиций – на этой идее основана встреча «трех товарищей»;
• Использовать техники вроде спецификации на основе примера, маппинга примеров и маппинга фич, структурируя обсуждения и добиваясь вышеупомянутого единодушия.

Вы можете полностью отказаться от описания ожидаемого поведения в формате Gherkin «Если – Когда – Тогда», и не создавать автоматизированные приемочные тесты на этом основании, но техники стадии обнаружения пригодятся практически любой команде, вне зависимости от ее процессов специфицирования / очистки / дизайна.

Заблуждение №2: BDD – это только автоматизация

Последний момент подводит нас ко второму заблуждению о BDD, о котором я хочу поговорить – к идее, что в BDD все крутится вокруг автоматизации. Я сталкивался с множеством команд, утверждающих, что практикуют BDD, хотя на самом деле они просто наклеивают слой абстракции с «Если – Когда – Тогда» поверх своей автоматизации при помощи таких инструментов, как Cucumber и SpecFlow. Превращение примеров и спецификаций в автоматизированные приемочные тесты – это, конечно, важная часть BDD, но она далеко не единственная.

Как я говорил ранее, BDD – это в первую и главную очередь техника, упрощающая коммуникацию и нацеленная на единодушное понимание, что именно должно делать наше ПО. Внедряя только автоматизационную часть BDD-процесса, вы пропускаете этот момент, и, следовательно, возможность для команды плыть на одной волне и снизить риски ошибочных интерпретаций, недопониманий и ложных предположений о поведении ПО.

К тому же простое добавление слоя Gherkin к коду автотестов зачастую не несет почти никакого смысла, особенно если учитывать потраченные на его создания и поддержку усилия. В этом случае слой Gherkin, внедренный при помощи Cucumber или SpecFlow – просто еще одна абстракция поверх вашего кода. И как и в случае с любым уровнем абстракции, существует он, как правило, за счет гибкости (слой абстракции лишает вас ряда возможностей) в пользу простоты использования (слой абстракции делает код читабельнее и проще в написании).

Я уже писал про слои абстракции, и хоть та статья больше концентрировалась на codeless-инструментах, Gherkin, примененный только в фазе автоматизации – просто еще один пример такого слоя абстракции, причем даже не наиболее полезный или мощный. Вообще я полагаю, что практически все «фреймворки тест-автоматизации», использующие Gherkin-инструменты вроде Cucumber и SpecFlow, не поддерживаемые важными для BDD обсуждениями, куда лучше справятся без этого слоя.

Иными словами Gherkin – плохой (если честно – ужасный) вариант, если вы хотите применять его в качестве псевдо-языка программирования.

Однако, возразите вы, я хочу, чтобы люди понимали, что делают мои приемочные тесты!

Отвечу: возможно, этого можно добиться куда более подходящими способами. Вот мои рекомендации:

• Убедитесь, что код тестов действительно будет регулярно читаться людьми, которые не умеют или не хотят читать код. Зачастую реальная потребность намного ниже, чем заявлено. Вы правда думаете, что ваш менеджер будет регулярно изучать все до единого тесты? Я думаю, ему есть, чем заняться.
• Воспользуйтесь инструментами вашего языка программирования или API своего любимого инструмента, чтобы сделать все максимально читабельным. Можно многого добиться, не притронувшись к Gherkin. По ссылке – советы для приемочных тестов через интерфейс. Они написаны на Java, но применимы и для других языков.
• Расскажите им, что делают ваши тесты. Куда эффективнее, чем полагаться на обратный инжиниринг Gherkin-галиматьи.

Вкратце: без основополагающих для BDD обсуждений не беритесь за приделывание Gherkin поверх всего и вся.

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