Прежде всего, если вы напишете свои тесты, чтобы охватить «требуемый уровень тестов» или требование «иметь какие-то тесты вообще» с уже выполненной производственной реализацией, будет слишком поздно. В большинстве случаев проведение тестов в первую очередь на основе ваших требований, контракта, варианта использования или чего-либо еще более оптимально. Тем не менее, я не знаю вашу ситуацию и то, что вы пытаетесь реализовать, поэтому воспринимайте это как предложение и переходите к ключевой вещи, о которой вы спрашиваете.
Ваш JUnit (предпочтительно 5) и Тесты Mockito, которые, вероятно, используют MockMvc, являются очень хорошими модульными (подобными) тестами для охвата проблем веб-коммуникации, таких как: типы запросов HTTP, тип контента, кодировка, параметры ввода и вывода JSON (де) сериализация, обработка ошибок, и др c. Их лучше всего тестировать с использованием сервисного уровня по издевательству. Благодаря этому вы можете легко охватить множество веб-кейсов без необходимости подготавливать данные в базе данных и т. Д. c.
Необходимо также проверить ядро logi c. В зависимости от того, что это, возможно, было бы целесообразно протестировать его единичным способом (проще всего написать, он может охватить множество, в том числе и угловых) случаев. Он может быть дополнен некоторым набором интеграционных тестов, чтобы убедиться, что он отлично работает и в интеграции (Spring Beans, DB и др. c.).
При желании вы также можете написать некоторый тест E2E из веб-вызов через (реальные) HTTP-запросы через контроллеры, службы к базе данных / хранилищу данных (если есть), но я бы ограничил его только наиболее важным сценарием ios, чтобы использовать его в конвейере CI / CD для проверки того, что развертывание Закончено успешно.
Отказ от ответственности. Я нашел этот подход полезным во многих ситуациях, но определенно в некоторых других случаях было бы неплохо изменить точку баланса, чтобы лучше применять тестирование.