Pull to refresh

Comments 13

Это было очень длинно :-)
Но спасибо за прекрасную статью.

Началась статья за здравие, кончилась за упокой. Я не совсем понял, если моки и стабы так плохи и монолитическая облачная структура на одном компе тоже попахивает, то как же тогда тестировать например общение с БД? Ведь все же знают что тестить лучше с белого листа, а следовательно нужно иметь БД на машине разработчика, удалять данные после каждого теста, тоже самое в CI. Docker например упрощает в этом плане жизнь, но ведь автор против docker-compose up.


Вот еще бы помимо пурги автор привела бы реальные примеры и подкрепила бы их расчетами о степени эффективности выявления багов того или иного подхода.


Так же не убедила она и об абсолютной нужде тестирования в продакшене. Если вы используете CloudFormation в связке с serverless и деплоите на aws то ваши среды абсолютно зеркальны, в чем тогда хайп тестов в продакшене?

> то как же тогда тестировать например общение с БД?

Видимо, надо выделять части, которые требуют общения с БД в отдельные (end-to-end?) тесты, и гонять их на dev. А если вообще все 20 контейнеров требуют БД — значит в архитектуре что-то не так. Хотя YMMV, конечно.
В целом, в публикации много толковых и практичных мыслей. Я бы сказал что не столько откровения, сколько очевидная реальность. Да и отладка на проде была не раз. Там уж точно самые реалистичные данные и проблемы, которые никогда не будут на синтетических окружениях tst/uat. Только цена ошибки там в разы больше.
Идею о том, что все эти сервисы можно развернуть локально на моем Macbook во время разработки сервиса API, можно назвать смехотворной (и нет, я этого не делаю).

А вот с этим могу поспорить. Нет ничего хуже отлаживать распределенную систему. И если возможно все компоненты запустить в одном процессе — это в сотни раз ускоряет разработку и отладку и раннее нахождение проблем.
Как думаете, сложно ли эмулировать инфраструктуру AWS (S3, SQS, RDS, Redshift) в JVM процессе?
> А вот с этим могу поспорить.
Можете конечно) Но когда у вас 300+ микросервисов, как в Soundcloud, то все их развернуть на одной машине, да еще и поддерживать в актуальном состоянии, да еще и со всей конфигурацией, близкой к продакшену, это действительно занятие для мазохистов
Сначало было увлекательно, потом слепили все в кучу…

тесты, конечно, здорово и полезно, но не увидел в статье упоминания TDD, тесты же не ради тестов…

есть логика функции\метода, описывается юнит тест логики с моками и т.п., реализуется, тест говорит ОК, добавляется работа с БД, создается интеграционный тест. помоему никакой магии.

оно все индивидуально от случая, проект над которым работал содержал чуть более 10ти микросервисов, go+mysql, развертывание dev-окружения делалось запуском одного bat-файла в windows, и делалось в тех редких случаях, когда была необходимость за раз прогнать все тесты, и все что нужно — наличие mysql на компе QA\QC.

К примеру, случай, когда микросервисы должны возвращать ответы в одном шаблоне… для этого обычно делают пакет\библиотеку, тест пишется на целевой код, а не покрывается тестами каждый сервис, используемый эту либу\пакет…

К чему это я… ах да… если тест содержит моки, разумный подход — понять цель создания моков и их природу, а не вестись на хайп и сразу: виновен.
тесты, конечно, здорово и полезно, но не увидел в статье упоминания TDD, тесты же не ради тестов

Спустя год, но все же отвечу:
В масштабах всей индустрии, мы по-прежнему привязаны к методологиям тестирования, изобретенным в далекую от нас эпоху, которая разительно отличалась от той реальности, в которой мы находимся сегодня. Люди по-прежнему увлечены идеями вроде полного покрытия тестами (настолько сильно, что в некоторых компаниях merge будет заблокирован, если патч или бранч с новой фичей приводит к понижению степени покрытия кодовой базы тестами более, чем на определенную долю процента), разработкой через тестирование и полным end-to-end тестированием на системном уровне.
Лично я до конца не определился имеет ли смысл разворачивать всё локально (при условии что оно заведомо влезет). Есть и плюсы, и минусы. Наверное, имеет смысл локально поднимать то, с чем непосредственно работаешь и его зависимости типа баз и редисов, а остальное держать общее для всех разработчиков и тестировщиков. С другой стороны, как ни странно, но всю инфраструктуру зачастую легче поднять локально, чем частично, если это частично динамически меняется. Скажем, с утра нужен просто один микросервис с его базой, а в обед другой, плюс фронт к нему, плюс их общий раббит и редис. Я пытался так делать — сложно, гораздо сложнее чем иметь локально 2 полных окружения для двух веток.

По тестам:
отказываться от юнит-тестов без io для сервисов со сложной логикой смысла не вижу. io для них вещь инфраструктурная, логика от не зависит, даже от абстракций над ним. В интеграционных тестах мокаем абстракции io или используем легковесные имплементации, в функциональных уже нужно ставить реальные.
Локально проще проводить отладку, профилирование. Нет интерференции между разработчиками — не нужно писать в групповом чате «Я занимаю dev3. Не влезай — убьет». Единственный вопрос — сложность развернуть так для некоторых технологий и проектов «прибитых гвоздями» к инфраструктуре.
Я про dev-test инфраструктуры, где интерференции нет. Скажем, два десятка сервисов, соответствующих продакшену, и только те, которые собираешься менять «форкаешь» к себе на локальную машину.
Читал читал и дочитал. А толку?
Ну работал человек тестировщиком, потом за прилежность повысили и стал чуть чуть кодить ну и тесты уже не ручками а кодом реализовывать. Судя по всему человек общительный и голосистый(вон сколько выплеснул), ну а значит опять повысили теперь он модный девопс. Ну а профит то в чем? Как была в голове каша так и осталась. Как поддержкой занимался так и занимается. А леса за деревьями так и не увидел.
А если по теме статьи, то все можно было уложить в три предложений:
1) Стоимость тестов — самый дешевый(быстрый) это компилятор! а не юнит. Второй…
2) Мониторить продакше это хорошо и чем больше у вас метрик тем лучше.
3) Тесты и в частности ТДД это не только про то что метод работает так как задумывалось, это еще и про многие ограничения накладываем на разработчиков приводящие к удешевлению(сокращение времени разработки и поддержания), доки, примеры,…
Ну там не только мониторинг в продакшене упоминается. Вы забыли про canarying, flagging. Напрямую к микросервисам это конечно не относится, может применяться и для монолитов, насколько я понимаю, но все же) Вообще статься в целом полезная, я для себя взял на заметку несколько инструментов и практик
Статью прочитала всю, и честно говоря, ожидала другого от такого названия. Ощущение сумбурности и хаоса очевидно присутствуют, но мне очень созвучны мысли, которые я не раз применяла у себя на проектах:
1. Тестирование в продакшене — это хорошо, особенно для распределенных систем, что позволяет найти скрытые баги, которые не выявишь без реальной нагрузки.
2. Тестирование в пре-продакшине недостаточно, полностью согласна при разговоре о распределенных системах.
3. Unit тесты, сейчас переживают определенный этап переосмысления. Если посмотреть в корень unit тестирования, то это покрытие кода тестами, но оно совершенно не говорит, о качестве кода и, тем более, качестве приложения. Например, на одном из проектов, где я была консультантом, в unit тестирование вынесли все проверки преобразования данных, что помогло в дальнейшем сосредоточится на функциональности приложения. Так что можно ожидать от unit- тестирования, нового витка эволюции.
4. Разворачивать или не разворачивать локально — это свой выбор для каждого проекта, но на моем опыте, полезнее всего оказывался комбинированный подход – параллельно поднятая копия системы в облаке + локальное поднятие определенных сервисов для проверки.
5. Мониторинг в продакшине — это хорошо, но за частую разобраться откуда на самом деле идет ошибка, проблематично. Мы из этой ситуации выходили тем, что в продакшин системе посылали специальные сигналы, которые маркировали как тестовые, и точно знали, где и когда они должны появится. Где не появились, там, очевидно, сбой и надо разбираться. Я к тому, что одного мониторинга все-таки недостаточно.

Sign up to leave a comment.