весенний отдых до c - сервисный слой насмешливый

Question

недавно я видел, как в блоге говорилось, что "для целей документации мы используем mocking для сервисного уровня (в среде, использующей spring rest, делаем c)", поэтому в этом посте используется аннотация, подобная Spring @MockBean, для обслуживания объекта слоя.

но я думаю, что если я имитирую сервисный уровень -> пружинный остаток делает c всегда успешное тестирование, потому что фиктивный сервисный объект всегда возвращает намеченный результат, а пружинный отдых делает c тест всегда получает один и тот же предполагаемый результат от симулированного сервиса объект.

так что я думаю, что это не правильно, но,

я хочу узнать о том, что лучше или как вы используете объект обслуживания с пружинным упором, сделайте c

просьба ответить

Answer 1

Является ли хорошей идеей насмехаться над уровнем сервиса при использовании Spring REST Docs, в значительной степени зависит от личных предпочтений.

Возможный недостаток насмешки над уровнем сервиса заключается в том, что это возможно для документации чтобы не совпадать с фактическим поведением службы. Это подрывает способность REST Docs помогать вам поддерживать документацию и сервис в синхронизации c.

. Преимущество насмешек над уровнем сервиса заключается в том, что он может облегчить документирование сценария ошибок ios или сценария. ios, что в противном случае потребовало бы много настроек. Я полагаю, что в случае ошибок лучше использовать общий подход для всего API и последовательно использовать стандартные коды ошибок HTTP. Если вы сделаете это, необходимость документировать ответы об ошибках для каждой конечной точки в сервисе уменьшится.

Это оставляет документирование более сложного сценария ios, который требует большой настройки. В этом случае может оказаться целесообразным ограниченное использование макетов, но я все же хотел бы создать как можно больше документации, не полагаясь на макеты.