Почему я больше не использую Cucumber при автоматизации тестирования

Один из важных принципов для инженера - признать свою вину. Должен признать, что использую Cucumber неправильно :)

Если вы прочитаете другую мою статью, то обнаружите, что я всегда пытаюсь найти разные способы для быстрого тестирования: короткий agile-процесс с осмысленной методологией затрат времени, чтобы помочь команде создать качественный продукт.

Определение BDD из википедии.

BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD). Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке.

Что такое Cucumber

Cucumber - это инструмент для поддержки формата BDD и способ написания тест-кейса с помощью операторов Given-When-Then.

В идеале тест-кейсы разрабатываются среди разработчиков, QA и бизнес-участников и других нетехнических людей в формате "Given-When-Then" и выполняются по завершении разработки, чтобы обеспечить соответствие кода бизнес-требованиям.

Все это уже сказано, но заметили ли вы, что в этом процессе происходит трансформация тест-кейса?

Разработанный тест-кейс (слева) НЕ МОЖЕТ использоваться в коде Cucumber (справа), он был преобразован в своего рода технический код в формате Given-When-Then. Вы, может быть, будете категорически против меня, вы подумаете, почему мы не соблюдаем один и тот же код? Посмотрите на сценарий ниже.

Feature: Search

Scenario: I can search successfully
Given I am in home page
 When I search "abc"
 Then I see "abc" is exist
Scenario: I can search by auto suggestion
Given I am in home page
 When I search "abc" by auto suggestion
 Then I see "abc" is exist
Scenario: I can search by auto by press enter
Given I am in home page
 When I search "abc" by press enter
 Then I see "abc" is exist

-----------------------------

Scenario: I can search successfully
Given I am in home page
 When I type "abc" in search filed
  And I click search button
 Then I see "abc" is exist
Scenario: I can search by auto suggestion
Given I am in home page
 When I type "abc" in search filed
  And I select search suggestion
 Then I see "abc" is exist
Scenario: I can search by press enter
Given I am in home page
 When I type "abc" in search filed
  And I press enter
 Then I see "abc" is exist

Есть 3 способа поиска, как описано выше. Сравнивая первые 3 сценария и последние 3 сценария, разница заключается в том, что первый написан на языке бизнеса, а второй - на языке действий.

У вас есть 2 варианта:

реализовать все бизнес-шаги как шаг “I search” в первых 3 сценариях.
реализовать все на языке действий как в последних 3 сценариях.

Используя 1-е решение, через полгода у вас будет взрывной рост шагов, и тогда станет очень дорого:

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

Используя 2-е решение, тогда становится очень дорого:

обеспечивать QA, разработчикам, бизнес-и нетехническим участникам информацией о всех именах элементов, используемых в click/press/etc, и их изменениях в будущем
поддерживать этот формат теста как критерий приемки в бизнесе, который трудно читать и понимать

Если вы не хотите использовать ни 1-е решение, ни 2-е решение. Тогда мы должны преобразовать Business BDD в Technical BDD.

Таким образом, люди, которые разработали тест-кейс, будут писать на бизнес-языке BDD, люди, которые пишут автоматизированный тест, преобразуют его в правильные шаги на уровне действий и создадут файлы BDD .feature.

Давайте посмотрим, где мы тратим наше время:

Вам необходимо поддерживать дополнительный слой в коде - шаги.
Вам нужно преобразовать Business BDD и написать свой собственный Technical BDD, но никто его не читает и не использует.
Вам необходимо связать свои собственные тесты Technical BDD с хорошо написанными тест-кейсами Business BDD в системе управления тест-кейсами.

Делать все это только для того, чтобы вы выглядели более занятыми? Люди все еще могут сказать:

Мы используем формат BDD как мост между бизнес и техническими специалистами.

Если вы один из этих людей, то стоит продолжить читать статью.

Я, может быть, не только я, обнаружил, что мы действительно перепутали (или неправильно поняли с самого начала) две вещи:

дизайн тест-кейса в формате BDD
реализация автотеста в формате BDD

Дизайн тест-кейса в формате BDD не означает, что наш код должен на 100% соответствовать Given-When-Then, и использование формата Given-When-Then не означает, что у вас BDD.

Посмотрите на следующий код для того же тест-кейса, что и выше:

describe("Search", () => {

  it("get result by click search button", () => {
      pageHome().visit()
                .type("[data-testid='search-input']", "abc")
                .click("[data-testid='search-btn']")
      searchResult.should('be.visible')
  });
  
  it("get result by auto suggestion", () => {
     pageHome().visit()
               .type("[data-testid='search-input']", "abc")
               .click("[data-testid='search-suggestion-item']")
     searchResult.should('be.visible')
  });
});

Что вы получаете:

Не нужно поддерживать слой шагов, меньше кода, а также быстрое тестирование и быстрая обратная связь
QA и Dev могут внести свой вклад в этот тест
QA и Dev могут поддерживать тест при изменении локатора
Нет риска, когда присоединится новый член команды

Вся команда заботится о качестве - это уже не просто слова.

В чем моя идея:

Создавайте тест-кейсы на языке BDD, пишите на бизнес-языке в системе управления тест-кейсами (например, TestRail, JIRA Test case и т. д.). Таким образом, вы по-прежнему пользуетесь методологией BDD и поддерживаете связь между техническим и бизнесом отделами.
Реализуйте автотесты в стиле модульного тестирования на основе тест-кейсов BDD, никаких .feature или Given-When-Then.
BDD не только про «Given-When-Then» в вашей сторе! BDD - это процесс поощрения сотрудничества между разработчиками, QA и нетехническими или бизнес-участниками проекта, а также предоставление стандартного способа описания бизнес-требований. BDD != Напишите тест-кейс в Cucumber.

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Почему я больше не использую Cucumber при автоматизации тестирования

Report Page