О чем статья: о том как в разработке сервисов отдаю предпочтение интеграционным тестам уровня сервиса, вижу в этом значительную пользу и с какими трудностями имею дело.
Интеграционная логика и бизнес логика, дать определения и значения
Обзервабилити, тест который медленный, но наглядно показывающий что-то
Тесты важнее кода. Изменения тестов и кода идут в параллельных таймлайнах с нахлестом.
Цель в доставке функциональностей с минимизацией затрат на разработку и поддержку кода.
Задачи:
-
Реализация желаемого бизнес поведения
-
Соблюдение Контрактов интеграционного характера (sla, api)
-
Создания условий, позволяющих минимизировать затраты на поддержку.
-
Рефакторинг (на мой практике гарнизонами планирования функциональностей - квартал, мы рассматриваем инициативы в начале и планируем доставку, мы точно знаем что мы реализуем в ближайший квартал, дальше ничего не знаем, если думаем что знаем - скорее всего будем разочарованы), поэтому невозможно строить долгоиграющий дизайн, тем более если сервис только появился. Важно чтобы сервис был эволвобильным (легко и дёшево меняться) с сохранением контракта. Интеграционные енд - то- енд тесты уровня сервиса помогают значительно.
-
Доступность и актуальность информации о текущей бизнес логике приложения (влияет на оценку времени разработки, в любой момент времени знаем что и как работает - например документация по апи содержит только интеграционную логику)
Дисклеймер: 1 Статья для тех, кто пишет код с багами и использует тесты для их нахождения. Или тех, кому интересно?
может содержать баги стремящиеся попасть на прод и кто выбрал тесты, как средство
что использование тестов сводит к минимуму появление багов в проде
2 в данной статье я в том числе поделюсь своими мыслями и опытом касательно интеграционных тестов и тдд. Я постараюсь обьяснить, а ни в чем-то убедить. Я не ставлю свой целью убедить , я хочу описать причины.