Статья про то, что в Kotlin Serialization есть аннотация, позволяющая управлять именем сериализуемого свойства? Как и у любой другой библиотеки для работы с JSON?
Так в вашем примере со слоями тот же MockBean используется.
Я в своих проектах выработал простое решение - везде применяются SpyBean, и объявляются они один раз в базовом классе. Там где нужно - им можно задать поведение, как мокам. Где не нужно - они будут вести себя как настоящие бины. И контекст при этом будет создан только один раз.
Интеграционный тест с использованием @SpringBootTest нужен как минимум для проверки того, что контекст поднимается и нет никаких ошибок в конфигурации.
И тут уже встает вопрос, а если мы всё равно будем поднимать полный контекст, зачем нам дополнительно ещё поднимать отдельные слои контекста?
дело не столько в том, что возвращаются какие-то лишние данные, а в том - что так внешний контракт зависит от внутренних нюансов реализации (того как мы маппим сущность на хранилище и т.д.)
Запишите тогда ещё моё пожелание. У умного Яндекс пульта больше поддерживаемых виртуальных пультов, чем у умного Яндекс хаба (с функцией умного пульта). Хаб - более дорогое устройство и было очень неприятно обнаружить, что он не может работать с моим кондиционером, с которым отлично справился дешевый пульт. Причём технически сигналы он такие посылать может - копирование пульта работает (просто пользоваться в таком варианте очень неудобно). Очень хочется чтоб базы виртуальных пультов были общие.
А ещё логи бывают вне приложения. Например, на балансерах/гейтвеях.
У вас замена имен у свойств при сериализации вшита в описание самих структур. Каким образом это отключается в разных окружениях?
Кажется, вам нужно было просто включить сжатие ответов и всё https://docs.spring.io/spring-boot/how-to/webserver.html#howto.webserver.enable-response-compression
Для удобного дебага, чтения логов и т.д.
Статья про то, что в Kotlin Serialization есть аннотация, позволяющая управлять именем сериализуемого свойства? Как и у любой другой библиотеки для работы с JSON?
Такая статья в твит поместилась бы, мощно
Так в вашем примере со слоями тот же MockBean используется.
Я в своих проектах выработал простое решение - везде применяются SpyBean, и объявляются они один раз в базовом классе. Там где нужно - им можно задать поведение, как мокам. Где не нужно - они будут вести себя как настоящие бины. И контекст при этом будет создан только один раз.
Интеграционный тест с использованием @SpringBootTest нужен как минимум для проверки того, что контекст поднимается и нет никаких ошибок в конфигурации.
И тут уже встает вопрос, а если мы всё равно будем поднимать полный контекст, зачем нам дополнительно ещё поднимать отдельные слои контекста?
Настолько не официальный, что буквально живет на домене vuejs.org? https://pinia.vuejs.org/
Это давно официальная рекомендация, Vuex мёртв
Порядок условий не важен
Так люди хотят именно Postgres в браузере, а не какую-то другую поделку, которая даже не про SQL.
ISO-8601 только. А то у вас про турбинное масло)
https://habr.com/ru/articles/870640/comments/#comment_27737930
IncidentResponse :)
Чаще всего не нужно смешивать объекты запроса и ответа
дело не столько в том, что возвращаются какие-то лишние данные, а в том - что так внешний контракт зависит от внутренних нюансов реализации (того как мы маппим сущность на хранилище и т.д.)
Id может быть и в DTO, а выставлять наружу сущность базы - антипаттерн.
Вероятно, стоит упомянуть о том, что такие манипуляции приводят к необходимости заново поднимать контекст.
Можно тогда ещё и colima добавить в тест?
https://github.com/abiosoft/colima
А почему статья в хабе $mol находится?
Запишите тогда ещё моё пожелание.
У умного Яндекс пульта больше поддерживаемых виртуальных пультов, чем у умного Яндекс хаба (с функцией умного пульта). Хаб - более дорогое устройство и было очень неприятно обнаружить, что он не может работать с моим кондиционером, с которым отлично справился дешевый пульт. Причём технически сигналы он такие посылать может - копирование пульта работает (просто пользоваться в таком варианте очень неудобно).
Очень хочется чтоб базы виртуальных пультов были общие.
извиняюсь, а как расшифровывается ЕВВЧДКН?)
Гугл только ваши посты выдает
Вероятность первого - 1/10, вероятность второго - 9/10. Или я что-то не так понимаю?
про консоли это отдельная история же, с видеокартой никак не связанная