В случае, если API REST BDD Cucumbers Gherkins содержит конкретные сведения об API или данных

Question

Я бы хотел задать этот вопрос, так как кажется, что это точка обсуждения, и я хотел бы узнать об этом сообщества.

Чтобы дать вам немного информации о том, как работает группа, в которой я работаю, и задайте этот вопрос в каком-то контексте, мы пишем огурцы для RESTful API на сеансе под названием «Три амигоса». Три Amigos в основном означают, что будет Tech Lead, разработчик (один или несколько) и BA (один или несколько), участвующих в определении критериев приемлемости для истории. В рамках этой сессии БА обычно управляет написанием огурцов для огурцов.

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

Scenario: Engine size should appear in the car 
Given a car exists 
When I request the car 
Then the car should have a "1700cc" engine capacity 

Или вы могли бы написать это как

Scenario: Engine size should appear in the car 
Given a "Mazda/ModelABC" car exists with an engine capacity 
When I GET "Mazda/ModelABC" 
Then the response should contain "1700cc" engine capacity 

Теперь первый один в моих глазах проще всего читать, но не будет способствовать повторному использованию кода (это большая сделка?). Второй способствует повторному использованию кода и написан с точки зрения заинтересованного лица, то есть разработчика, но бизнес-аналитик (BA) не будет писать его так, чтобы сделать сеанс Three Amigos довольно бессмысленным.

Учитывая два подхода, которые являются наиболее рекомендуемым выбором? Я выбрал первый подход в моем случае, но мне интересно узнать, что аргументы для любого метода или если есть некоторые достойные статьи, люди могут создавать резервные копии предложений, которые предполагают, какой подход действительно должен использоваться.

Спасибо.

Answer 1

Вы можете поместить «IMHO» после каждого абзаца в этом ответе. Это мой опыт после выполнения BDD/Specification на примере в течение четырех лет.

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

Огурец - это инструмент, который облегчает общение. Единственная причина использовать Cucumber (и добавленные дополнительные абстракции) заключается в том, что это упростит понимание друг друга, чем другие форматы. Если бы мы были только разработчиками в команде, нам было бы лучше использовать код.

Итак, чтобы ответить на ваш вопрос, если ваши BA и клиенты понимают GET, POST и т. Д., Возможно, было бы целесообразно использовать это в спецификации. Но будьте осторожны, что вы только что связали спецификацию с реализацией. Изменения будут распространяться даже на сценарии Cucumber.

Скорее всего, ваш первый пример - это формат, который ваши клиенты и BA могут напрямую связываться и понимать.

Но, конечно, это зависит от уровня технических деталей, которые используют члены вашей нетехнической команды. Постарайтесь всем понять.

BDD - около связь.

Вот некоторые доклады по теме, что я нашел полезным и в одном случае тщательно развлекательное:

• BDD as you meant it
• Refuctore your Cukes
• Cuke Envy