27 января в офисе компании ScrumTrek прошла встреча, посвященная Behavior Driven Development (BDD) и ее применимости в разработке, инфраструктуре и архитектуре. Ниже — краткие итоги.
Что такое BDD и кому оно надо?
Вначале Сергей Кокорев рассказал об опыте применения BDD при разработке собственного продукта. Про опыт печальный, но поучительный. Печальный он от того, что один из клиентов не воспринял BDD тесты как спецификацию и ценность тестов резко упала, поучительный — потому что заставил задуматься: «А где действительно они, эти BDD, нужны?».
В качестве основных выводов зафиксировали, что BDD нужны, если выполняется как минимум одно из следующих условий:
- Бизнес согласен их писать по правилам, согласованным с разработкой (тогда у вас BDD)
- Из них нужно собирать программу и методику испытаний
- Если нужен промежуточный язык для общения между специалистами в разработке и тестировании
- Если эти тесты будут использованы как актуальная документация
Казалось бы, все логично и понятно. Правда, реальность сурова и мало кто из бизнеса согласен писать тесты по правилам, пусть и на понятном ему языке, но бывали и случаи явления чуда.
BDD в архитектуре и инфраструктуре
Посмотрим чуть подробнее на пункт «Если нужен промежуточный язык для общения между специалистами в разработке и тестировании». Суть в том, что у вас могут быть крутые js-, go-, java-, python-разработчики, каждый отлично знает свой язык программирования, но вот деталей другого языка не знает. И становится не так-то просто собрать общую картину покрытия бизнес-тестами. Да, мы можем оценить покрытие, SonarQube нам в помощь, но что касается бизнес-смысла этих тестов — тут все не так однозначно.
Конечно, это слабый аргумент. До тех пор, пока мы не посмотрим на других специалистов — админов, архитекторов и специалистов по безопасности. И вот тут начинается самое интересное. Тесты безопасности нередко живут отдельно от репозитория разработки в своих инструментах и со своей атмосферой. Нагрузка, производительность, — где-то в другой части галактики, а инфраструктурные… в дикой природе встречаются совсем редко, но это пока. Инфраструктура как код, безусловно, толкает тестирование инфраструктуры вперед семимильными шагами.
Так о чем это я. О специалистах. Представьте теперь, что у вас не только функциональные тесты, но и тесты на инфраструктуру, дизайн системы, нагрузку, контракты, производительность безопасность. И вы хотите в едином стиле выдержать всю стратегию обеспечения качества. Вот где BDD действительно хороший помощник. Любой специалист смотрит в книгу в тест и понимает, что этот тест проверяет. К тому же эти тесты живут в Delivery Pipeline, вокруг которого и строится взаимодействие людей с разной экспертизой.
Теперь заглянем глубже, в микросервисы. Для BDD-теста нужен исполняемый код на некотором языке программирования. Если мы пишем тесты на Selenium для UI, то это нас не сильно трогает, но если мы пишем исполняемый код на языке микросервиса? Мы решили перейти с Java на Go. Go-разработчик смотрит на Java-тесты и разбирается, ошибается, ругается матом. Если же у нас тесты на BDD, то в целом нет проблем — сам тест на понятном, человеческом языке, берем за основу и описываем шаги на Go.
Примеры инфраструктурных тестов и тестов дизайна можно посмотреть в моей презентации:
Спасибо всем, кто принял участие в митапе! До новых встреч!
Анонсы будущих митапов в Facebook-группе по архитектуре и дизайну и Telegram-канале по микросервисам.
Полезные ссылки
- Server Testing
- Chef
- Ansible
- Terraform
- Kubernetes
- Other
- Infrastructure Mocking
- ArchUnit
