В примере RESTBucks авторы представляют полезную диаграмму состояний, которая описывает действия, которые клиент может выполнять с сервисом.
Откуда такая диаграмма состояния приложения? Ну, это вытекает из требований, конечно.
Поскольку мне нравится определять требования с помощью примеров , давайте посмотрим, как мы можем получить диаграмму состояния приложения из требований стиля BDD .
Пример: диаграмма состояния RESTBucks
Вот три сценария для истории заказа напитка :
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
|
Scenario: Order a drink Given the RESTBucks service When I create an order for a large, semi milk latte for takeaway Then the order is created When I pay the order using credit card xxx1234 Then I receive a receipt And the order is paid When I wait until the order is ready And I take the order Then the order is completed Scenario: Change an order Given the RESTBucks service When I create an order for a large, semi milk latte for takeaway Then the order is created And the size is large When I change the order to a small size Then the order is created And the size is small Scenario: Cancel an order Given the RESTBucks service When I create an order for a large, semi milk latte for takeaway Then the order is created When I cancel the order Then the order is canceled |
Давайте посмотрим на это более подробно, начиная со сценария счастливого пути .
1
2
|
Given the RESTBucks service When I create an order for a large, semi milk latte for takeaway |
Первая строка говорит мне, что есть служба REST, по некоторому заданному URL рекламного щита . Вторая строка говорит мне, что я могу использовать метод POST
для этого URI, чтобы создать ресурс Order с заданными свойствами.
1
|
Then the order is created |
Это говорит мне, что POST
возвращает 201 с расположением созданного ресурса Order.
1
|
When I pay the order using credit card xxx1234 |
Это говорит мне, что существует pay
действие (отношение ссылки).
1
|
Then I receive a receipt |
Это говорит мне, что ответ действия pay
содержит представление ресурса Receipt.
1
|
And the order is paid |
Это говорит мне, что есть ссылка с ресурса Receipt обратно на ресурс Order. Это также говорит мне, что Заказ теперь находится в paid
статусе.
1
|
When I wait until the order is ready |
Это говорит мне, что я могу обновить Order, используя GET
пока какой-то другой процесс не изменит свое состояние на ready
.
1
|
And I take the order |
Это говорит мне, что есть действие (ссылка).
1
|
Then the order is completed |
Это говорит мне, что Орден сейчас в completed
состоянии.
Анализ двух других сценариев аналогичным образом дает нам диаграмму состояний, которая очень похожа на исходную в примере RESTBucks.
Единственное отличие состоит в том, что эта диаграмма содержит дополнительное действие для перехода от получения к заказу. Эта навигация также описана в книге, но не показана на схеме в книге.
Использование методов BDD для разработки RESTful API
Используя сценарии BDD, довольно просто обнаружить диаграмму состояния приложения. Это не должно вызывать удивления, поскольку синтаксис Given/When/Then
сценариев BDD — это просто еще один способ описания состояний и переходов между состояниями.
От диаграммы состояния приложения это только маленький шаг к полной модели ресурса. Когда модель ресурсов реализована, вы можете повторно использовать сценарии BDD, чтобы автоматически проверить, соответствует ли реализация требованиям.
В общем, методы BDD могут нам очень помочь при разработке RESTful API.
Ссылка: | Управляемые поведением API-интерфейсы RESTful от нашего партнера по JCG Ремона Синнема из блога по безопасной разработке программного обеспечения . |