BDD и микросервисы
Наше решение основано на микросервисах. С другой стороны, наш ИТ-директор ожидает, что мы будем практиковать разработку на основе поведения для каждой новой функции.
Можно ли управлять BDD в архитектуре микросервисов? Исходя из вашего опыта, рекомендуется ли применять BDD против такой архитектуры, или вы считаете, что нам следует непосредственно взглянуть на интеграционное тестирование?
[РЕДАКТИРОВАТЬ]
Точнее, на мой взгляд, BDD-тесты должны проверять бизнес-логику и только бизнес-логику. Во многих средах сценарии BDD Tests создаются держателями скейтбордов с DSL. Тесты BDD имеют тенденцию сходиться к эксклюзивным практикам "невежественных в отношении инфраструктуры". С другой стороны, интеграционные тесты должны проверять, что решение соответствует целевой инфраструктуре (они выполняются DevOps?) И только инфраструктуре. Когда бизнес-функции "распределены" по микросервисам, вам следует высмеивать почти все (инфра и бизнес) в вашей среде BDD Tests (это должна быть локальная среда), и имитация бизнеса сильно ослабляет ваши цели. Как вы думаете, эти практики совместимы?
3 ответа
Почему вы думаете, что BDD и интеграционное тестирование разные?
BDD просто означает управление вашим дизайном в соответствии с желаемым поведением, обычно выражаемым через набор приемочных тестов.
Эти тесты могут быть "интеграционными тестами", которые включают в себя множество [микро] сервисов, или они могут быть тестами, которые определяют желаемое поведение одного сервиса или одного класса в этом сервисе. В идеале, на всех этих уровнях будут проходить тесты. Важно, чтобы вы указали желаемое поведение и использовали его для управления разработкой.
То, как реализована ваша система, в некоторой степени не имеет значения, если она демонстрирует ожидаемое поведение. Для тестов высокого уровня, которые рассматривают систему как черный ящик, это верно, и чем ниже вы идете, и чем ближе вы подходите к реальному коду, тем меньше это становится правдой (поскольку в этот момент вы эффективно тестируете реализацию).
Поэтому я бы сосредоточился на поведении, ожидаемом от новых функций, и сначала напишу спецификации для этих приемочных тестов, а затем внедряю ваши службы для выполнения требуемого поведения, добавляя тесты более низкого уровня по мере необходимости с практической точки зрения, учитывая, что более низкий уровень тесты проходят, тем более вероятно, что они будут хрупкими и нуждаются в изменении по мере изменения вашей реализации.
РЕДАКТИРОВАТЬ
На основании вашего вопроса отредактируйте.
Я не согласен, что тесты 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, но они тестируют различные аспекты системы.
Я думаю, что эта статья может вам помочь: архитектура программного обеспечения обеспечивает границы для TDD, BDD, DDD, RDD и чистого кода
Я считаю, что способность выполнять функциональное тестирование на сервисе является хорошим показателем качества. Интеграционное тестирование дорогое, медленное и болезненное. Интеграционное тестирование не место, чтобы утверждать, что ваше поведение корректно, его историческая цель - определить, правильно ли взаимодействуют компоненты.
В этой статье представлен хороший подход к структурированию функций и этапов тестирования для достижения удобства обслуживания, модульности и масштабируемости в приложениях на основе микроархитектуры. Взгляни на это.