Comments 13
Но спасибо за прекрасную статью.
Началась статья за здравие, кончилась за упокой. Я не совсем понял, если моки и стабы так плохи и монолитическая облачная структура на одном компе тоже попахивает, то как же тогда тестировать например общение с БД? Ведь все же знают что тестить лучше с белого листа, а следовательно нужно иметь БД на машине разработчика, удалять данные после каждого теста, тоже самое в CI. Docker например упрощает в этом плане жизнь, но ведь автор против docker-compose up
.
Вот еще бы помимо пурги автор привела бы реальные примеры и подкрепила бы их расчетами о степени эффективности выявления багов того или иного подхода.
Так же не убедила она и об абсолютной нужде тестирования в продакшене. Если вы используете CloudFormation
в связке с serverless
и деплоите на aws
то ваши среды абсолютно зеркальны, в чем тогда хайп тестов в продакшене?
Идею о том, что все эти сервисы можно развернуть локально на моем Macbook во время разработки сервиса API, можно назвать смехотворной (и нет, я этого не делаю).
А вот с этим могу поспорить. Нет ничего хуже отлаживать распределенную систему. И если возможно все компоненты запустить в одном процессе — это в сотни раз ускоряет разработку и отладку и раннее нахождение проблем.
Как думаете, сложно ли эмулировать инфраструктуру AWS (S3, SQS, RDS, Redshift) в JVM процессе?
тесты, конечно, здорово и полезно, но не увидел в статье упоминания TDD, тесты же не ради тестов…
есть логика функции\метода, описывается юнит тест логики с моками и т.п., реализуется, тест говорит ОК, добавляется работа с БД, создается интеграционный тест. помоему никакой магии.
оно все индивидуально от случая, проект над которым работал содержал чуть более 10ти микросервисов, go+mysql, развертывание dev-окружения делалось запуском одного bat-файла в windows, и делалось в тех редких случаях, когда была необходимость за раз прогнать все тесты, и все что нужно — наличие mysql на компе QA\QC.
К примеру, случай, когда микросервисы должны возвращать ответы в одном шаблоне… для этого обычно делают пакет\библиотеку, тест пишется на целевой код, а не покрывается тестами каждый сервис, используемый эту либу\пакет…
К чему это я… ах да… если тест содержит моки, разумный подход — понять цель создания моков и их природу, а не вестись на хайп и сразу: виновен.
тесты, конечно, здорово и полезно, но не увидел в статье упоминания TDD, тесты же не ради тестов
Спустя год, но все же отвечу:
В масштабах всей индустрии, мы по-прежнему привязаны к методологиям тестирования, изобретенным в далекую от нас эпоху, которая разительно отличалась от той реальности, в которой мы находимся сегодня. Люди по-прежнему увлечены идеями вроде полного покрытия тестами (настолько сильно, что в некоторых компаниях merge будет заблокирован, если патч или бранч с новой фичей приводит к понижению степени покрытия кодовой базы тестами более, чем на определенную долю процента), разработкой через тестирование и полным end-to-end тестированием на системном уровне.
По тестам:
отказываться от юнит-тестов без io для сервисов со сложной логикой смысла не вижу. io для них вещь инфраструктурная, логика от не зависит, даже от абстракций над ним. В интеграционных тестах мокаем абстракции io или используем легковесные имплементации, в функциональных уже нужно ставить реальные.
Ну работал человек тестировщиком, потом за прилежность повысили и стал чуть чуть кодить ну и тесты уже не ручками а кодом реализовывать. Судя по всему человек общительный и голосистый(вон сколько выплеснул), ну а значит опять повысили теперь он модный девопс. Ну а профит то в чем? Как была в голове каша так и осталась. Как поддержкой занимался так и занимается. А леса за деревьями так и не увидел.
А если по теме статьи, то все можно было уложить в три предложений:
1) Стоимость тестов — самый дешевый(быстрый) это компилятор! а не юнит. Второй…
2) Мониторить продакше это хорошо и чем больше у вас метрик тем лучше.
3) Тесты и в частности ТДД это не только про то что метод работает так как задумывалось, это еще и про многие ограничения накладываем на разработчиков приводящие к удешевлению(сокращение времени разработки и поддержания), доки, примеры,…
1. Тестирование в продакшене — это хорошо, особенно для распределенных систем, что позволяет найти скрытые баги, которые не выявишь без реальной нагрузки.
2. Тестирование в пре-продакшине недостаточно, полностью согласна при разговоре о распределенных системах.
3. Unit тесты, сейчас переживают определенный этап переосмысления. Если посмотреть в корень unit тестирования, то это покрытие кода тестами, но оно совершенно не говорит, о качестве кода и, тем более, качестве приложения. Например, на одном из проектов, где я была консультантом, в unit тестирование вынесли все проверки преобразования данных, что помогло в дальнейшем сосредоточится на функциональности приложения. Так что можно ожидать от unit- тестирования, нового витка эволюции.
4. Разворачивать или не разворачивать локально — это свой выбор для каждого проекта, но на моем опыте, полезнее всего оказывался комбинированный подход – параллельно поднятая копия системы в облаке + локальное поднятие определенных сервисов для проверки.
5. Мониторинг в продакшине — это хорошо, но за частую разобраться откуда на самом деле идет ошибка, проблематично. Мы из этой ситуации выходили тем, что в продакшин системе посылали специальные сигналы, которые маркировали как тестовые, и точно знали, где и когда они должны появится. Где не появились, там, очевидно, сбой и надо разбираться. Я к тому, что одного мониторинга все-таки недостаточно.
Тестирование микросервисов: разумный подход