TsyklopSergunkaХорошо давайте по второму кругу. Как это делается в нашей конторе по правилам.

Микросервисы тестятся так же как и любой другой сервис.

Сначала пишутся сценарии тестирования т.е. описывается Cucumber в стиле если это то так, если вот это то вот так.

Потом ставится микросервис и запускаются сценарии. Все это делается через классический CI/CD c покрытием либо на coverity или sonarqube.

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

А вот у меня на работе сколько бы люди не тестировали и сколько бы тестов не писали программисты все равно вылазят баги и бывает что сервисы не работают/отключаются и т.д. Так что хз на самом деле...

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

тесты не обязаны избавить от багов. они обязаны тебе дать понять что твой код работает в определенных (тобою) условиях так как ты хочешь. и всё.

насчет задира к фразе микросервисы их определению и т.п.

мое имхо - тестировать не надо только геттеры и сеттеры (если в них ничего нету кроме чтения и присваивания) остальное тестить надо.

если в твоем микросервисе нихера нету ни логики ни кода (тут кто то пишет их из 3х строчек) -- то прости, нафиа вообще ты этот мусор пишешь? где 98% это бойлерплейт и 2% это вывод в логи.

Самая ублюдочная это серверлесс облачная херня

Petro123Озверин,
+1
неужели он тебя переубедил против того тчо микросервис это 2-4 строчки и всё?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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