BDD и микросервисы

Question

Наше решение основано на микросервисах. С другой стороны, наш ИТ-директор ожидает, что мы будем практиковать развитие, основанное на поведении, при каждой новой функции.

Возможно ли управлять BDD в архитектуре микросервисов? Основываясь на вашем опыте, хорошо ли использовать BDD против такой архитектуры, или вы считаете, что нам следует непосредственно посмотреть на интеграционное тестирование?

[EDIT]

Более точно, на мой взгляд, BDD тесты, как ожидается, для проверки бизнес-логики, и только бизнес-логику. Во многих рамках сценарии BDD Tests создаются владельцами скейтбордов с DSL. Тесты BDD, как правило, сводятся к исключительной практике «Инфраструктура невежды». С другой стороны, тесты интеграции должны проверять, соответствует ли решение целевой инфраструктуре (они выполняются DevOps?) И только инфраструктуре. Когда бизнес-функции «распределяются» по микросервисам, вы должны издеваться над всем (инфраструктурой и бизнесом) в среде BDD Tests (это должна быть локальная среда), и насмешливый бизнес сильно ослабит ваши цели. Считаете ли вы, что эти методы совместимы?

Answer 1

Почему вы думаете, что BDD и тестирование интеграции различны?

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

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

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

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

EDIT

На основе вашего вопроса редактирования.

Я не согласен с тем, что тесты BDD должны проверять только бизнес-логику. На самом деле обычно тесты BDD более сфокусированы на тестировании системы в целом, причем все части объединены вместе. Сказав, что BDD - это всего лишь стиль тестирования, указав желаемое поведение и может быть применен к любому уровню приложения. Вы можете протестировать один класс, указав поведение с использованием синтаксиса Gherkin, и мы иногда это делаем. мы также указываем ожидаемое поведение всей системы, используя Gherkin и ожидаемое поведение наших услуг по отдельности. Естественно, эти тесты будут немного отличаться от формата, который мы планируем.

Для системных тестов мы могли бы иметь спецификацию так:

Scenario: user can perform action A 
    Given I am a user with access to some feature A 
    And feature A is enabled for the user 
    When I call perform action A with parameters 'Bob' and 'John' 
    Then A 'BobJohn' is created 
    And notifications are sent to the current user 

для отдельных услуг, которые мы могли бы иметь тесты, как

Scenario: create messages are handled correctly 
    Given the service is set up 
    When a message arrives to create a 'BobJohn' 
    Then a new entry is added to the database with the key 'BobJohn' 
    And an outgoing notification message for 'BobJohn' is created 

Для отдельных классов мы могли бы иметь тесты, как

Scenario: Notifier class should send notifications via all users preferred means 
    Given the current user wants notification by Twitter 
    And the current user who wants notification by email 
    When I send the notification 'BobJohn' to the current user 
    Then the twitter notifier should be invoked with 'BobJohn' 
    And the email notifier should be invoked with 'BobJohn' 

Это все тесты стиля BDD, но они проверяют различные аспекты sys ПЭМ.

Answer 2

Я думаю, что эта статья может помочь вам: Software architecture provides boundaries for TDD, BDD, DDD, RDD and clean code

Answer 3

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