ImperousВсем привет!

Давайте представим проект, в котором есть (иерархия, где-то такая):
1) сущности (геттеры, сеттеры, доп методы)
--
2) репозитории
--
3) сервисы
4) утилиты
5) исключения
--
6) контроллеры
7) трансферобжекты
--
8) допишите что ещё может быть.

Что из этого принято тестировать?
Мне вот думается, что по хорошему стоит уделить внимание только контроллерам (слою), и его всячески терзать на все возможные варианты, ибо именно там можно создать ситуации, которые затронут всё.
Несколько мыслей.

1) Тестировать геттеры и сущности не надо.
2) Тестировать надо то место в коде, где есть бизнес-логика. Тоесть, к примеру есть контроллер или процессор
который что-то делает в режиме черного ящика. Или серого. Тоесть если у него есть некий вход и некий детерминированный
выход, то надо покрывать тестами именно это.
3) В идеале у вас количество тестов должно быть равно количеству бизнес-кейсов. Вот просто
можно брать user-story из JIRA и буквально обзывать тестовые методы так-же как и были названы все юзер-стори.
4) Конвертеры и функции и трансфер обжекты - сам бог велел тестировать тем более, что у них
нет обычно состояния и они идеально тестабельны.
5) Код который плохо тестируется имеет смысл улучшить. Например, если какой-то ДАО содержит
код доступа к БД + бизнес-логику лучше разделить на отдельно ДАО и отдельно бизнес-процессор,
и протестить процессор как чистую функцию.
6) Старайтесь испльзовать меньше Mockito. Признак идеально тестабельного кода - это как-раз отсутствие
необходимости в моках. Обычно сторонники Мокито боятся вносить изменения в основной код в направлении
улучшения тестабельности, но при этом тратят сутки и недели времени на тонкую и настройку верификаторов
и шпионов которые должны замокать какой-то сложный объект.
7) Периодически запускайте jacoco плагин и смотрите отчот о покрытии. Это будет набор таких html-ек
где зеленым цветом покрашен покрытый тестами код и красным цветом код, который еще не протестировать.
Красны - это ваша цель. Разумеется без параноидальности. Геттеры и сеттеры не надо а только то что
имеет логику.

Petro123Микросервисы лучше в топике не упоминать.
Там в методах не более 3-5 строк должно быть. Что тестировать?
И их придумали не для проблем в разработка.
Пока видны только проблемы.
Со стороны диалектики или терминологии. Принято считать что микросервисы возвращяют ресурсы. В этом (на минуточку)
есть сильное отличие от веб-сервисов где действительно инкапсулируется логика. Следуя ресурсной
диалектике, тестирование "правильного" микросервиса - безсмысленно по своей сути.

Что тестировать? Коллекции? Репозитарии?

Я полностью согласен что обсуждение микросервисов здесь - offtop.

Давайте кто-то поднимет это обсуждение отдельно.

ОзверинPetro123пропущено...
значит микро функции)))) количество строк 3-5. Не больше.

нет никаких микрофункций. Кол-во строк на метод или класс определяется принципами типа solid, kiss и так далее. Причем тут микросервисы?
Он имеет в виду рекомендацию толи Фаулера толи Боба - делать функции маленькими и делать их как можно меньше.