Статьи

Критерии приемки должны быть исполняемыми

Рассмотрев неудачу в Backwater Bank inc, вы бы подумали, что в моем последнем блоге было сказано почти все, что можно сказать о Agile User Stories. Ну, это оказывается не так. Если вы посмотрите пример заказа чековой книжки из сценария Backwater Bank inc, вы увидите, что он включает некоторые критерии приемлемости:

1
2
3
4
5
6
7
8
Title: Order Cheque Book
As a customer
I want to access my online account
So that I can order a new cheque book
 
Acceptance Criteria
1) The bank will only send out a cheque book if the customer is in credit.
2) The user can only request a cheque book if the bank has his/her complete address details.

Одна из основных проблем при написании тестов (и да, есть проблемы) заключается в том, что вы должны тестировать правильные вещи. Один из способов сделать это – убедиться, что имена ваших тестовых методов описывают поведение тестируемого вами класса: что он должен (и не должен) делать. Например, в моих тестах для примера калькулятора индекса массы тела (BMI), используемого в моем блоге по защитному программированию , у меня есть тесты с именем:

1
2
  @Test(expected = NullPointerException.class
  public void test_null_height_input() { }

…и

1
2
  @Test(expected = NullPointerException.class
  public void test_null_weight_input() {  }

Из этих сигнатур методов можно надеяться, что нулевой вес или рост приведут к NullPointerException

Именно Дэн Норт в своем введении в развитие , основанное на поведении , заметил, что вы можете продвинуть эту идею на один шаг вперед. Если вы можете определить требуемое поведение для простого модульного теста, то почему вы не можете определить требуемое поведение для приемочных тестов? Взяв идеи из книги Эрика Эвана « Доменно-управляемый дизайн», Дэн и Крис Мэттс предложили «вездесущий» язык для описания требований, добавив идею включения сценариев в истории.

Это я или слово повсеместно встречается в Agile? Это на самом деле просто означает «Присутствует, появляется или встречается везде». В случае гибкой разработки вы можете легко заменить слово «простой». Я думаю, что это на самом деле означает, что разработчики должны изучать словарь решаемой ими проблемы, а не клиент, изучающий любой жаргонный язык разработки.

Проще говоря, они придумали четыре вездесущих слова, которые последовательно определяют сценарий. Эти слова даны , когда , тогда и А , и они подходят друг к другу так:

1
2
3
4
Scenario: The name of the scenario
Given an initial condition
When something happens
Then this is the result

При необходимости добавляется слово «И», чтобы расширить сложность сценария:

1
2
3
4
5
6
7
Scenario: The name of the scenario
Given an initial condition
And another condition
When something happens
And something else happens
Then this is the result
And this is also the result

Это работает так, что у каждой истории, которую вы пишете, будет свой собственный набор критериев приемлемости, выраженных в формате «задано, когда, потом». Например, глядя на заказ чековой книжки выше, вы можете придумать что-то вроде этого.

1
2
3
4
5
6
Scenario: Order a Cheque Book
Given the account is in credit
And the user has been authenticated
And the user's address is available
When the user clicks on 'order a cheque book'
Then send cheque book to user

… И когда у вас есть сценарий «счастливого потока», вы можете добавить все альтернативные потоки, чтобы создать полную и полезную историю, которую можно использовать при приемочном тестировании.

1
2
3
4
5
6
Scenario: Order a Cheque Book, no address available
Given the account is in credit
And the user has been authenticated
And the the bank does not have complete user address details
When the user clicks on 'order a cheque book'
Then ask user for complete their address
1
2
3
4
5
Scenario: Order a Cheque Book, user is overdrawn
Given the account is overdrawn
And the user has been authenticated
When the user clicks on 'order a cheque book'
Then refuse to send user a cheque book

Как только у вас есть ваши сценарии, они могут быть добавлены в вашу карточку истории. Например:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Title: Order Cheque Book
As a customer
I want to access my online account
So that I can order a new cheque book
 
Scenario: Order a Cheque Book
Given the account is in credit
And the user has been authenticated
And the user's address is available
When the user clicks on 'order a cheque book'
Then send cheque book to user
 
Scenario: Order a Cheque Book, no address available
Given the account is in credit
And the user has been authenticated
And the the bank does not have complete user address details
When the user clicks on 'order a cheque book'
Then ask user to complete address
 
Scenario: Order a Cheque Book, user is overdrawn
Given the account is overdrawn
And the user has been authenticated
When the user clicks on 'order a cheque book'
Then refuse to send user a cheque book

Если есть случай для «эпического» рассказа, то есть ли случай для «эпического» сценария? Если вы посмотрите на мой первый удар по этим сценариям, вы увидите, что они немного расплывчаты, непроверяемы и требуют немного больше работы. Например, я сказал «Учитывая, что счет в кредит» , что приводит к еще большему количеству вопросов:

  1. Как вы определяете «кредит»?
  2. Речь идет о случае, когда есть положительный баланс на счете?
  3. Есть ли у пользователя превышение лимита сквозняков?

В этом случае я определяю «в кредит» как положительное сальдо, что означает, что я могу использовать реальные числа в сценариях, и, следовательно, они становятся реальными примерами:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Title: Order Cheque Book
As a customer
I want to access my online account
So that I can order a new cheque book
 
Scenario: Order a Cheque Book
Given the balance of the account is 200
And the account number is 12345
And the user has been authenticated
And the user's address is 15 Credibility Street
When the user clicks on 'order a cheque book'
Then reply YES to the user's request
 
Scenario: Order a Cheque Book, user is overdrawn
Given the balance of the account is -150
And the account number is 12345
And the user has been authenticated
When the user clicks on 'order a cheque book'
Then reply NO to the user's request
 
Scenario: Order a Cheque Book, zero account
Given the balance of the account is 0
And the account number is 12345
And the user has been authenticated
When the user clicks on 'order a cheque book'
Then reply NO to the user's request
 
Scenario: Order a Cheque Book, no address available
Given the balance of the account is 200
And the account number is 12345
And the user has been authenticated
And the the user's address is UNKNOWN
When the user clicks on 'order a cheque book'
Then reply NO_ADDRESS to the user's request

Преимущество наличия истории, содержащей множество конкретных примеров, а не несколько расплывчатых сценариев, состоит в том, что вы можете связать свои истории с вашими тестами, чтобы сценарии в ваших статьях стали тестами. В этом блоге я перешел от идеи нечетких критериев приемлемости к тестируемым сценариям. Теперь нужны инструменты, которые позволят нам выполнить эти сценарии в качестве тестов. Введите jbehave и огурец . Кажется, и jbehave, и Cucumber делают одно и то же, но именно реклама сайта Cucumber лучше всего описывает их функциональность:

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

Ссылка: Критерии принятия должны быть выполнены от нашего партнера JCG Роджера Хьюза в блоге Captain Debug’s Blog .