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

Question

Я новичок в Gherkin/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

Поведение 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

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

Answer 3

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

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

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

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

На этом уровне вы можете просто положить "Given, When, Then" statements in comments, и это достаточно хорошо. Шаги уровня класса не используются повторно так же, как шаги на системном уровне, поэтому их использование в многократных абстракциях не так важно, как их легко изменить. Придерживайтесь J/N/WhateverUnit и высмеивайте остальные.