ОзверинmaytonДавайте вернемся в самое начало. В родительский топик.
В основу микросервисов (в реализации REST) положен принцип
доступа к т.н. ресурсам. Тоесть правильно организованный
REST-сервис просто предоставляет доступ к репозитарию
с ограниченной семантикой операций. Взять. Положить.
Найти все. Обновить.

Вопрос. В свете вышесказанного мной. Имеет ли смысл
тестировать логику такого REST-сервиса в отрыве от
приложения в целом?

нет такой основы. Что за? Откуда ты это черпаешь? Причем опять! Основа микросервиса - это выделенная бизнес единица...она может вообще без реста реализована, на каком нить json-rpc или gRPC или через mq.
Это архитектура rest`а подразумевает, что все есть ресурс, причем совершенно необязательно, что это какая-то статика.
кстати да, откуда такое мнение что рест прям только со статикой. под запросом гет/ентити может крыться 100500 строк кода которые эти ентити достают создают и т.д. и т.п. не говоря о том что ты можешь и парамами играться и всякое такое. кроме того описание реста само по себе такое же не менее туманное как и любые другие спецификации.

выделенная бизнес-единица. согласен. именно так и есть. она должна быть гранулярной и с минимумом функционала, относящегося только и сугубо лишь к ней самой.

ну а что там потестировать - всегда найдется.

Petro123Уж слишком широкий вопрос.
Причем теоретический.
Во первых, в микросервисах есть БЛ. Куда же она делась?
Ведь микросервисы это не ресурсы. Например микросервис:
ЗарегестрироватьЗаявку()
Да. В нём 3-5 строк всего, но и БЛ есть.
...
Во вторых, в больших компаниях и тестирование большое - свой DSL, свои тестировщики. Весь набор типов тестов. Тесты вне проектов и в проектах.
Тесты пишут не программисты.
В маленьких или хайп компаниях это лишняя трата денег.
какие тесты? уточняй. юнит и интеграционные - пишут программисты. это в нормальных конторах а не пет-кид-проектах. некоторые вообще пишут вначале тест потом код.

а вообще это было бы забавно что вот я говнокод накидал который тестами обложить в принципе не возможно потому что он говно а следом за мной мальчик-юнит-тестировщик с криками гоугоу гоу их обкладывает моками и тестами )) хехех. а я при этом ему объясняю как оно должно работать и что я от этих сервисов и методов ожидаю.

Petro123andreykaTкстати да, откуда такое мнение что рест прям только со статикой.есть обратная сторона.
При рест БЛ в ангуляре на клиенте. Что тогда на бэке остается?
ты ща описал прям 99% всех современных приложений. на беке остается бл, сесурити, авторизация и всё остальное два звена из трех.

забавно ну давай че бэк вообще выбросим будем сразу давать прямой доступ к бд с твоего ангуляра (это возможно) и пусть сами с ней работают. зачем на лишние прослойки?

Petro123andreykaTкакие тесты? уточняй.табличку выкладывал
в той таблице написано, что за тесты ответственен программист. или ты еще одну таблицу выкладывал?

ОзверинandreykaT будем сразу давать прямой доступ к бд с твоего ангуляра (это возможно) и пусть сами с ней работают. зачем на лишние прослойки?

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

ОзверинandreykaTпропущено...

ну типа к бд ж можно по тцп подключиться открытием сокета. на жеесе ж это возможно? ) (честно не в курсе). если нет ну можно сделать минимальный бэк который будет тупо трубой от фронта к базе. и пусть фронты совершенно ни в чем себе не отказывают. даже авторизация аутентификация через бд.

спринг давно ввел понятие RepositoryRestResource;) Там даже безопасность можно прикрутить.
да но всё-равно специфика может быть своя у приложения зависимости и т.п. в целом - да.