Насколько конкретным должен быть мой пример приемочного теста?

Question

Я новичок в корнишоне / ATDD / BDD. Я готовлю следующий приемочный тест:

Given a user is waiting for an operation to complete
    And the operation is <percent>% complete
When <threshold> seconds elapse
Then a progress indicator should be displayed
    And the progress indicator should display "<percent>%"

Является ли это достаточно конкретным, или мне следует изменить данное условие, чтобы оно представляло более конкретный пример (в терминах SBE), например, ссылаясь на конкретную персону, а не просто на "пользователя", или ссылаясь на конкретную "операцию", которая выполняется (например,: получение списка клиентов)?

Спасибо Тони

Answer 1

BDD

Behavior Driven Development - это все разговоры между командой разработчиков и бизнесом. Файлы компонентов и сценарии в них всегда должны относиться к конкретной бизнес-потребности, функции или возможности, которые означают, что и бизнес, и команда разработчиков полностью понимают между собой, в чем именно они изложены.

В качестве примера:

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: I get flyer miles
   Given I book a flight 
    And this flight earns 100 miles
   When I land
   Then my account should have 100 miles added to it

Вопрос в том, описывает ли это всю проблему или нужно больше информации? Сможет ли команда разработчиков что-то построить, используя этот разговор (как вы о SBE)?

Будет ли это лучше?

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: Passenger gets flyer miles
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is rewarded 100 miles

 Scenario: Passenger missed their flight
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is not scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

 Scenario: Passenger gets kicked off the plane
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
     But the ticket is removed from the flight
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

Все дело в ясности и, как правило, больше в том, как описывается поведение системы по отношению к бизнесу.

Ваш пример

Лично я не стал бы писать Сценарий с целью тестирования индикатора выполнения, так как бизнес не должен интересоваться реализацией каких-либо используемых компонентов (их не волнует индикатор загрузки, они просто заботятся о том, чтобы информация на самом деле нагрузки).

Это было бы лучше в качестве юнит-теста на мой взгляд.

Answer 2

Прогресс-бары - это эстетика.

Единственный реальный способ проверить эстетику - показать ее людям и увидеть, что они думают. A/B тестирование действительно хорошо для этого. BDD не особенно подходит для эстетики, потому что эстетика на самом деле не о желаемом поведении системы, а о желаемом поведении пользователей.

Мы все еще учимся тому, как эффективно программировать людей. До этого тестируйте эстетику на людях, а не на сценариях.

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

На этом уровне, вы можете просто поместить заявления "Дано, когда, потом" в комментарии, и это достаточно хорошо. Шаги на уровне класса не используются повторно так же, как шаги на системном уровне, поэтому превращение их в абстракции многократного использования не так важно, как упрощение их изменения. Придерживайтесь J/N/Wh независимо Unit и издевайтесь над остальными.

Answer 3

Да, вы должны быть более конкретными. Если у вас только один тип пользователя или этот тестовый пример применим к каждой группе пользователей, "пользователь", вероятно, достаточно хорош для вашего теста. Тем не менее, я думаю, что вы должны указать операцию, которую следует ожидать, потому что TDD полностью уверен в своем коде и в том, как вы можете быть уверены, что он работает везде, если вы не тестировали его для всех операций, которые могут вызвать задержка?