Как IN (:ids) раздувал Hibernate Query Plan Cache до 100+ МБ и почему ANY(:ids) спас прод

Раньше я сам оч любил Хибер)) Но чем глубже его изучаешь, чем больше сталкиваешься со всякими нюансами в проде, тем яснее, что это довольно сложный инструмент. Ошибиться или допустить незаметный для разработки кейс, который вылезет в рантайме оч легко
Поэтому у нас на платформенном уровне сейчас есть рекомендация по возможности уходить в сторону Spring Data JDBC или jooq, где меньше магии и больше контроля over sql)

MapStruct — смаппь меня, если сможешь

1. Тесты и так и так будут одинаковыми, ведь нужно протестировать всю логику маппинга) огромное преимущество - это null safe библиотека, как минимум все эти кейсы проверять не нужно

2. Про сбой - спорно, но окэй, такое бывает, нужно смотреть что генерируется.

3. В статье есть пример про вынос некоторой логики в отдельные классы, так же можно выносить общие маппинги в отдельные интерфейсы и тоже их использовать. Это очень удобно.

4. В IntelliJ idea есть шикарный плагин для map struct’a , который подсвечивает и видит весь синтаксис, даже в строках в expression

5. На самом деле map struct далеко не идеален, есть сложные вещи, например прикидывание в контексте нескольких параметров, но в статье про подводные камни не сказано(

MapStruct — смаппь меня, если сможешь

Некоторые пакеты можно исключать из покрытия, что является классной практикой. У нас, например, сущности и мапперы исключены из подсчета покрытия. Это можно гибко настраивать в JacoCo или сонаре.

Гайд по использованию JUnit 5, Mockito и AssertJ для проверки поведения кода

Спасибо ко комментарий! Из вашего кода в примере видятся лишние if'ы

//Первый, который всегда будет false
if(values.isEmpty()) {
   return
}
//Второй, который всегда будет false
if(firstElement == null) {
   return;
}

Остальные альтернативные сценарии возможны. Их нужно тестировать отдельно: мокать вызов клиента и выкидывать ошибку. Имеется ввиду сценарии orElseThrow . Почему jacoco считает их покрытыми - большой вопрос :)

И конечно, еще нужен альтернативный сценарий, когда метод eventService.sendEvent не вызовется по бизнес логике. Данные сценарии я специально не отражал в туториале, он и так получился довольно большой(

Вы правы на счет того, что jacoco не отслеживает покрытие ветки .ifPresent(eventService::sendEvent). По идее, здесь по бранчам покрыто 50%, хотя при генерации отчета index.html отображается 100%