Повсюду пихают примитивный вариант - тот, что заменяет конкатенацию строк. Ну и там от нее не заметно вреда, одна польза - читается проще. Если в коде складываются строки, скорее всего, замена будет выглядеть лучше.
Как я понял, главная проблема с $-синтаксисом, что уже есть куча строк, где используются такие темплейты. Могут возникнуть неожиданные коллизии. Например, с темплейтами в Спринге.
А держать все литералы в коде — это, может быть, приемлемо для хелло-ворлдов, но не для промышленных программ, где все тексты потенциально локализуемые, их пишут и правят копирайтеры, а не кодеры
Все и не требуется. Старый format никто удалять не пытается. Так что где хранить темплейты и привязывать ли их к контексту - на выбор разработчика. Более того, предыдущий вариант с процессорами делал возможность использовать темплейт как ключ, а локализованную строку забирать откуда хочешь по любым правилам.
Ах да, у нас же для этого был функционал query-builder'а, который и занимался безопасностью с учётом предметной области.
Так они и хотят (ради этого и был сыр-бор с процессорами), чтобы можно было написать query-builder, но так, чтобы читался попроще.
Если захочется проскалировать, добавив консюмера, то придется добавить и партицию. А это 1) ручная операция, 2) поломает партицирование по ключу (если используется)
Если завести 15 партиций на 10 консюмеров, то 5 из них будут нагружены в два раза больше чем 5 остальных.
Может показаться, что надо завести сотню-другую партиций, чтобы примерно распределить нагрузку поровну между изменяемым количеством консюмеров. Но каждая партиция - это минимум 6 открытых файловых дескрипторов на каждой ноде. И большое количество партиций - возможная проблема с Zookeeper.
Увы, приходится это все учитывать, по возможности, заранее.
А вам точно нужно протестировать вот прям все сценарии с граничными условиями?
Как раз нет. Я как раз про то, что со сквозными тестами нет нужды проверять все. А вот с юнит-тестами и контрактом как раз напротив. Если "воспринимать другой (микро)сервис как совершенно внешний", то и ожидать от него можно все, что угодно. У юнит-тестов плюс - быстрое исполнение - это Вы верно заметили. Но как понять, что он проверяет сценарий, которые случается и как понять, что сценарии, которые случаются - покрыты тестами?
наличие такого решения будет побуждать им пользоваться, писать еще больше интеграционных тестов и постепенно усугублять проблемы.
Да. Я сделал решение, чтобы им пользовались. Это не серебрянная пуля. Она позволяет махом проверить систему, но у нее есть цена. Для проверки одного микросервиса есть, например, @SpringBootTest, для проверки класса или функции - достаточно обычных тестов. У каждого типа - своя ниша и своя цена.
Мне кажется, что мы перешли от обсуждения конкретного решения к обсуждению, нужны ли end-to-end тесты вообще. Это так?
Понял. Я не предлагаю выдирать микросервисы из подсистемы. Если ваша подсистема включает, скажем, десять микросервисов - так и тестируйте десять микросервисов. В предлагаемом подходе нигде нет ограничений на количество (кроме ресурсов машины, на которой исполняете).
В целом этот подход ничем не отличается от обычных тестов на подсистему, но дает два преимущества: проще запускать из ide при разработке в рамках TDD + возможность прогонять тесты на этапе пулл-реквеста, не деплоя на энв.
Спасибо, понятно. Тут мне возразить нечего: если все возможное поведение всех микросервисов описано, одинаково понято и полностью покрыто юнит-тестами, то интеграционное тестирование функциональности не нужно.
Но да, я не доверяю разработчикам. Я сам разработчик и я себе не доверяю. Я подозреваю себя в том, что:
я плохо понял контракт
я недостаточно покрыл тестами граничные условия, а по границам может пролегать success story
мокая другой сервис, я не включил в ответы все возможные значения
Поэтому я успокаиваю себя тем, что добавляю сквозные тесты, которые покрывают хотя бы главные успешные сценарии и очевидные негативные.
Не знаю. Наверное для тех, кому не понравился цикл коммит/аппрув/мерж/деплой/прогон тестов/бага/возврат в начало. По сложности реализации у себя в проекте: наверное жунам будет сложно, но middle уже должен справиться.
Простите, не понимаю. Вы против сквозного тестирования? Вы против интеграционного тестирования? Вы против того, чтобы один микросервис обращался к другому?
Если ответ на последний вопрос "нет, не против", то как и в какой момент можно убедиться, что все правильно работает?
Да, если какая-то логика распределена по подсистеме, то лучше (а на каком-то уровне тестирования даже необходимо) тестировать её целиком. При этом в этой подсистеме может быть разное количество сервисов. Если количество сервисов больше одного, то можно применить подход, описанный в статье.
Причин же разбить систему на микросервисы существует много и это отдельная архитектурная задача. Здесь и разделение логики, и разные деплойменты, и изоляция ресурсов и многое другое.
Про окружение: сейчас мы используем Кафку - ее мы поднимаем также, как и остальные микросервисы. Оракл заменяем на h2. Можно использовать testcontainers - не вижу проблем (мы не используем по бюрократическим причинам)
Про запуск из идеи и docker-compose. Можно так. Я не уверен, но мне кажется, что тогда не получится сделать написание тестов частью разработки. Перед каждым прогоном придется заново паковать. Тут идея в том, что запуск интеграционных тестов с только что сделанными изменениями становится таким же простым, как и запуск юнит тестов.
Но есть и сложности: например, надо сформировать правильный класспас.
Он позволяет запускать микросервисы каждый со своим класспасом. И не надо предварительно собирать образы, пушить их и т.п. Таким образом можно встраивать написание интеграционных тестов прямо в процесс разработки, запускать их прямо из идеи, использовать их там, где юнит тесты уже не подходят.
Котлину проще. Там темплейты изначально. А исходники java просто перекомпилируют с новой версией.
Локализуемые логи - это что-то реально существующее? Я такого не встречал.
Почему verbose не настраивается? Настраивай, как хочешь. Если не хочешь, чтобы строки высчитывались каждый раз, используй лямбды. Что-то вроде этого:
Но разве это хуже вот этого:
Повсюду пихают примитивный вариант - тот, что заменяет конкатенацию строк. Ну и там от нее не заметно вреда, одна польза - читается проще. Если в коде складываются строки, скорее всего, замена будет выглядеть лучше.
Как я понял, главная проблема с $-синтаксисом, что уже есть куча строк, где используются такие темплейты. Могут возникнуть неожиданные коллизии. Например, с темплейтами в Спринге.
Все и не требуется. Старый format никто удалять не пытается. Так что где хранить темплейты и привязывать ли их к контексту - на выбор разработчика. Более того, предыдущий вариант с процессорами делал возможность использовать темплейт как ключ, а локализованную строку забирать откуда хочешь по любым правилам.
Так они и хотят (ради этого и был сыр-бор с процессорами), чтобы можно было написать query-builder, но так, чтобы читался попроще.
А откуда брались инстансы классов там, где Спринга не было?
А Кафка поддерживает другие альтернативы зукиперу, кроме собственного кворума?
Не логично. По крайней мере в общем смысле.
Если захочется проскалировать, добавив консюмера, то придется добавить и партицию. А это 1) ручная операция, 2) поломает партицирование по ключу (если используется)
Если завести 15 партиций на 10 консюмеров, то 5 из них будут нагружены в два раза больше чем 5 остальных.
Может показаться, что надо завести сотню-другую партиций, чтобы примерно распределить нагрузку поровну между изменяемым количеством консюмеров. Но каждая партиция - это минимум 6 открытых файловых дескрипторов на каждой ноде. И большое количество партиций - возможная проблема с Zookeeper.
Увы, приходится это все учитывать, по возможности, заранее.
Как раз нет. Я как раз про то, что со сквозными тестами нет нужды проверять все. А вот с юнит-тестами и контрактом как раз напротив. Если "воспринимать другой (микро)сервис как совершенно внешний", то и ожидать от него можно все, что угодно. У юнит-тестов плюс - быстрое исполнение - это Вы верно заметили. Но как понять, что он проверяет сценарий, которые случается и как понять, что сценарии, которые случаются - покрыты тестами?
Да. Я сделал решение, чтобы им пользовались. Это не серебрянная пуля. Она позволяет махом проверить систему, но у нее есть цена. Для проверки одного микросервиса есть, например,
@SpringBootTest, для проверки класса или функции - достаточно обычных тестов. У каждого типа - своя ниша и своя цена.Мне кажется, что мы перешли от обсуждения конкретного решения к обсуждению, нужны ли end-to-end тесты вообще. Это так?
Понял.
Я не предлагаю выдирать микросервисы из подсистемы. Если ваша подсистема включает, скажем, десять микросервисов - так и тестируйте десять микросервисов. В предлагаемом подходе нигде нет ограничений на количество (кроме ресурсов машины, на которой исполняете).
В целом этот подход ничем не отличается от обычных тестов на подсистему, но дает два преимущества: проще запускать из ide при разработке в рамках TDD + возможность прогонять тесты на этапе пулл-реквеста, не деплоя на энв.
Спасибо, понятно. Тут мне возразить нечего: если все возможное поведение всех микросервисов описано, одинаково понято и полностью покрыто юнит-тестами, то интеграционное тестирование функциональности не нужно.
Но да, я не доверяю разработчикам. Я сам разработчик и я себе не доверяю. Я подозреваю себя в том, что:
я плохо понял контракт
я недостаточно покрыл тестами граничные условия, а по границам может пролегать success story
мокая другой сервис, я не включил в ответы все возможные значения
Поэтому я успокаиваю себя тем, что добавляю сквозные тесты, которые покрывают хотя бы главные успешные сценарии и очевидные негативные.
Не знаю. Наверное для тех, кому не понравился цикл коммит/аппрув/мерж/деплой/прогон тестов/бага/возврат в начало. По сложности реализации у себя в проекте: наверное жунам будет сложно, но middle уже должен справиться.
Простите, не понимаю. Вы против сквозного тестирования? Вы против интеграционного тестирования? Вы против того, чтобы один микросервис обращался к другому?
Если ответ на последний вопрос "нет, не против", то как и в какой момент можно убедиться, что все правильно работает?
Кажется, я Вас не понимаю. Можете раскрыть подробнее, что кажется вам опасным?
Я созрел и описал то, что у нас получилось. Возможно, Вам будет интересно: https://habr.com/ru/post/682420/
Да, если какая-то логика распределена по подсистеме, то лучше (а на каком-то уровне тестирования даже необходимо) тестировать её целиком. При этом в этой подсистеме может быть разное количество сервисов. Если количество сервисов больше одного, то можно применить подход, описанный в статье.
Причин же разбить систему на микросервисы существует много и это отдельная архитектурная задача. Здесь и разделение логики, и разные деплойменты, и изоляция ресурсов и многое другое.
Про окружение: сейчас мы используем Кафку - ее мы поднимаем также, как и остальные микросервисы. Оракл заменяем на h2. Можно использовать testcontainers - не вижу проблем (мы не используем по бюрократическим причинам)
Про запуск из идеи и docker-compose. Можно так. Я не уверен, но мне кажется, что тогда не получится сделать написание тестов частью разработки. Перед каждым прогоном придется заново паковать. Тут идея в том, что запуск интеграционных тестов с только что сделанными изменениями становится таким же простым, как и запуск юнит тестов.
Но есть и сложности: например, надо сформировать правильный класспас.
А мы используем nanocloud
Он позволяет запускать микросервисы каждый со своим класспасом. И не надо предварительно собирать образы, пушить их и т.п. Таким образом можно встраивать написание интеграционных тестов прямо в процесс разработки, запускать их прямо из идеи, использовать их там, где юнит тесты уже не подходят.