Здравствуйте, ·, Вы писали:

·> D> У меня тут случился затуп и/или недопонимание:
·> D> Тестовая задача получить по rest информацию, отправить ее в message queue, получить оттуда и прочитав файл вернуть допинформацию если она есть. Код вышел таким:
·> D> https://bitbucket.org/Dziman/tt/src/2a84a61783ffa8907a0862b84c6822c3bd809b8e/?at=client_info
·> D> Что тут можно и имеет смысл тестировать юнит тестами?

·> ClientInfoManagementController покрывается хорошо. Можно покрыть что возвращаемый статус NOT_FOUND или OK в зависимости от поведения замоканного cardDetailsService.
Мне кажется что если мы мокаем cardDetailsService, то весь этот тест суть то же что и тестирование простых аксессоров.

·> CardDetailsServiceCSVImpl покрывается тоже. Например, такой тест: делаем "createClientInfo" и убеждаемся что getClientInfo возвращает то что надо. Скажем, этот тест проверит, что ты не перепутаешь колонки name и surname во время записи и чтения.
·> Ну и тесты поиска, возвращения списка, и т.п.
·> ClientInfoService покрывается тоже. Например, убедиться что correlationId не потерялся, что setSuccess проставляется правильно false/true, setCardNumber правильный и т.п.
·> ClientInfoServiceJMSImpl тоже можно покрыть, что, например, выбор correlationId происходит такой же. Ну и даже можно запилить тест, котоый проверит, что два запроса используют разные correlationId.
·> А однострочные методы с одним вариантом исполнения... да... можно и не тестировать.

ОК, описанные тесты вполне логичны и проверяют что-то значимое. Но в моем понимании это ни разу не юнит тесты, а интеграционные.