Обфусцированные и обезличенные данные обычно все же используются для end to end тестов на отдельном стенде, п не в рамках CI/CD. Для обычного пайплайна сборки асе же более характерно поднятие чистой БД в контейнере, ну или H2 на худой конец.
Теперь к тезисам:
Такая ситуация возможна, но это уже зависит от качества проведенного системного анализа.
Очевидно лучше писать тесты) Вы же можете протестировать не только отдельные классы с логикой, но и компонующий их сервис, исходя из того, что его составляющие работают корректно (вы же их протестировали).
Правильные юнит-тесты исподволь заставляют писать менее связанный код, поэтому рефакторинг не такой болезненный как может показаться. Если все таки больно, возможно вы все таки что-то делаете не так.
Юнит тесты отрабатывают за милисекунды.
Как уже ранее писал, тот же MockBean тоже пачкает контекст.
Я отчасти согласен с тем, что большое количество юнит тестов затруднит существенный рефакторинг, но это сделают и интеграционные тесты, однако юнит тесты при этом стимулируют писать менее связанный код.
На счёт важности скорости тестов я в корне не согласен, так как от этого зависит скорость обратной связи при разработке, чем быстрее разработчик получает обратную связь, тем легче двигается разработка, особенно в продукте с историей, в котором много логических нюансов и взаимосвязей.
Потому что при полноценном интегрционном тесте необходимо создавать настоящие данные, чтобы вся цепочка от данных до API корректно отработала. Вместо того чтобы эмулировать поведение среды, которая окружает тестируемый фунционал, её приходится буквально создавать. Тут можно апелировать, что есть же MockBean и т.д., но при его использовании будет поднят отдельный контекст, что ещё больше увеличит время.
Сори за поздний ответ, давно не заходил сюда. Это демка, поэтому тут опущена аутентификация, а так можно её включить в Loki, и передавать логопас в урле при подключении. https://grafana.com/docs/loki/latest/send-data/docker-driver/configuration/
На данный момент графана покрывает наши потребности, но в дальнейшем в планах разработать свою систему лейблов, чтобы эффективнее индексировать логи, а также добавить трейсинг (скорее всего заюзаем jaeger)
В локи и храним) Пока в режиме хранения в локальной ФС. Тут зависит еще все от того, как долго нужно логи хранить, у нас на стенде разработки время жизни логов - неделя, скорее всего в промышленной эксплуатации это время будет больше. Локи предоставляет много альтернатив для непосредственно хранения, при желании их можно куда-то в облако складывать.
Ну на самом деле, хоть сколько-то существенное время (15 мин) на внесение трудозатрат уходит у лидов (т.к. в моменте у них как правило несколько задач, которые они делают, проверяют и т.д.) рядовой разработчик/аналитик в день занимается максимум двумя задачами, и на внесение времени у него уходит минут 5.
Java не зиждется на Spring, на прошлой работе использовался в основном Apache Camel. Касаемо притязаний на middle позицию, знания по Spring я подтянул самостоятельно + много практики дал курс. Так что Middle позицию я все же заслужил)
Это совет)
Да, все так, я про них как раз написал в разделе slice-тестов
Обфусцированные и обезличенные данные обычно все же используются для end to end тестов на отдельном стенде, п не в рамках CI/CD. Для обычного пайплайна сборки асе же более характерно поднятие чистой БД в контейнере, ну или H2 на худой конец.
Теперь к тезисам:
Такая ситуация возможна, но это уже зависит от качества проведенного системного анализа.
Очевидно лучше писать тесты) Вы же можете протестировать не только отдельные классы с логикой, но и компонующий их сервис, исходя из того, что его составляющие работают корректно (вы же их протестировали).
Правильные юнит-тесты исподволь заставляют писать менее связанный код, поэтому рефакторинг не такой болезненный как может показаться. Если все таки больно, возможно вы все таки что-то делаете не так.
Юнит тесты отрабатывают за милисекунды.
Как уже ранее писал, тот же MockBean тоже пачкает контекст.
В slice нестрашно использовать @MockBean так как там поднимается только часть контекста и это быстро.
А вот про @SpyBean интересно, я бы глянул пример, если не жалко)
Я отчасти согласен с тем, что большое количество юнит тестов затруднит существенный рефакторинг, но это сделают и интеграционные тесты, однако юнит тесты при этом стимулируют писать менее связанный код.
На счёт важности скорости тестов я в корне не согласен, так как от этого зависит скорость обратной связи при разработке, чем быстрее разработчик получает обратную связь, тем легче двигается разработка, особенно в продукте с историей, в котором много логических нюансов и взаимосвязей.
Потому что при полноценном интегрционном тесте необходимо создавать настоящие данные, чтобы вся цепочка от данных до API корректно отработала. Вместо того чтобы эмулировать поведение среды, которая окружает тестируемый фунционал, её приходится буквально создавать. Тут можно апелировать, что есть же MockBean и т.д., но при его использовании будет поднят отдельный контекст, что ещё больше увеличит время.
Сори за поздний ответ, давно не заходил сюда. Это демка, поэтому тут опущена аутентификация, а так можно её включить в Loki, и передавать логопас в урле при подключении. https://grafana.com/docs/loki/latest/send-data/docker-driver/configuration/
На данный момент графана покрывает наши потребности, но в дальнейшем в планах разработать свою систему лейблов, чтобы эффективнее индексировать логи, а также добавить трейсинг (скорее всего заюзаем jaeger)
В локи и храним) Пока в режиме хранения в локальной ФС. Тут зависит еще все от того, как долго нужно логи хранить, у нас на стенде разработки время жизни логов - неделя, скорее всего в промышленной эксплуатации это время будет больше. Локи предоставляет много альтернатив для непосредственно хранения, при желании их можно куда-то в облако складывать.
У нас в данный момент такие штуки логируются в основном потоке, но на уровне логирования DEBUG.
спасибо, исправил)
Отладка кода. Я не уверен, что помимо вас существуют гуру, которые умеют исследовать нагрузку, стабильность и скорость системы с помощью дебагера.
Ну на самом деле, хоть сколько-то существенное время (15 мин) на внесение трудозатрат уходит у лидов (т.к. в моменте у них как правило несколько задач, которые они делают, проверяют и т.д.) рядовой разработчик/аналитик в день занимается максимум двумя задачами, и на внесение времени у него уходит минут 5.
Мы начали с java, сейчас и go перетащили, все вроде довольны))