Комментарии 5
Здесь можно наблюдать проблему, описанную выше как "Сложность определения объема тестируемых состояний из-за их рассредоточенности по коду теста" - часть проверяемых утверждений находится в блоке then, часть в блоке setup.
Можно попробовать использовать параметрические тесты для этого. Это позволяет разделить тестовые данные (описание кейса) и их применение (сам кейс).
Отличное замечение! Но мне кажется, что использование такого подхода хоть и повысит читаемость кода, но не решит описанную проблему, а лишь скроет ее.
Обычно именно такую проблему и решает. Получается, что у тебя есть выделенная модель (все в одном месте) и тесты по ней. Эторазделение позволяет контролировать и расширять покрытие отдельно от тестов. Если честно, не знаю как по другому поддерживать крупные системы с сотнями юнитов
К сожалению с мобилы неудобно пример вставить.
Хороший подход с RequestCaptor. Не думали создать PR в spring-test?
Разносим по полочкам этапы тестирования http запросов в Spring