Тестирование микросервисов

и, чтобы 2 раза не вставать:

ищу записи Moscow API Meetup, особенно

Валентин Полежаев, Inteliour «Практика разработки систем на основе микросервисов»

Ну или скажите, что этот митап - отстойный.

Ведь все сервисы используют один и тот же порт. Как быть к конфликтами портов?

ip адреса контейнеров то разные, так что тут проблем нет.

это и так понятно, а теперь кинъТе в меня ссылкой на бложик, где чувак рассказывает, как он применял докер для сабжа.

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

А что предлагает взамен?

ничего. ручками менять номер порта.

Зы. пока я тоже не понимаю, как мне нужно применить докер для сабжа.

зайди на #linux в rusnet ребята там должны растолковать, если вопросы правильно задашь, может и я подтянусь.

а вот наш сеньор говорит, что докер нинужен, он только приностит личний оверхед.

А вы с сеньором уже договорились, нагрузочное тестирование проводите или интеграционное?

интеграционное

По теме.

Я делал так. Писал сервис А, учил тест эмулировать интерфейс Б. Писал Б, учил тест эмулировать интерфейс А. Последним этапом учил тест быть проксей между А и Б. На каждом этапе можно с нужной детализацией проверять корректность запросов/ответов.

Докер не использовал.

у тебя двунаправленная зависимость что ли (А -> Б и Б- > А)?

REST-то проблемы. Точнее проблемы отсутствия декларативного описания протокола. В случае SOAP, используется плагин от SOAPui, который тыкается мордой в wsdl и сам поднимает на указанном порту mock-сервис. И да, имхо, даже после готовности сервиса Б, тестирование стоит проводить об моки, а не об реальный сервис.

и, чтобы 2 раза не вставать:
ищу записи Moscow API Meetup, особенно
Валентин Полежаев, Inteliour «Практика разработки систем на основе микросервисов»
Ну или скажите, что этот митап - отстойный.

Он только вчера прошел. Запись велась. Видео будет через неделю-две, наверное.

Вообще я склонен согласиться с вашим сеньором, конкретно для тестирования микросервисов невижу надобности в докере, докер это в первую очередь средство деплоя.

Я немного упростил, сервисов было больше) Суть в том, что я делал интеграционный тест, который мог прикидываться другими сервисами, а мог проксировать запросы к ним — и во всех режимах проверять запросы/ответы.

ЗЫ. Эти сервисы были не «микро», половина работала на SOAP, другая на REST, но концептуально по-моему это применимо и для микросервисов.

И да, имхо, даже после готовности сервиса Б, автоматизированное интеграционное тестирование стоит проводить об моки, а не об реальный сервис.

Вот собственно этого я и добивался. А причины? Выполнение автоматизированных интеграционных тестов - это задача только Jenkins или другой системы непрерывной интеграции?

С реальными сервисами нужно проводить уже ручное тестирование и только после того как пройдут интеграционные тесты?

ОК

и да, вот прочитав «Искусство модульного тестирования» Роя, у меня отпали все вопросы про то, как правильно писать юнит-тесты.

Есть ли тоже самое про интеграционные тесты?

Обычно, когда говорят про интеграционное тестирование, то говорят про тестирование интеграции между компонентам одного сервиса, а не между сервисами. Поэтому ты делаешь сервис, а потом проводишь его интеграционное тестирование дергая не по модулям, а уже в целом, пользуясь его API. Тоже самое касается потребителя этого сервиса. Когда ты тестируешь два сервиса в связке, то в этом случае обычно уже говорят про системное тестирование - тест всего в целом. Используют для этого обычно всякие тулы для автоматизации QA тестирования. Если GUI есть, то какой-нибудь Selenium, который идет по gui и прокликивает кейсы.

типичный пример «слышал звон не знаю где он».

разница между системным и интеграционным тестированием - не в том, сколько каких сервисов under test, а в том, с какой целью оно проводится:

интеграционное тестирование системы проводится для проверки интеграции между компонентами, которые могут быть какими угодно (сервисами, компонентами сервисов, сторонними API)

системное тестирвоание - для проверки high-level требований к системе, без упора на проверку внутренних взаимодействий

системное интеграционное тестирование - для проверки интеграции системы со сторонними компонентами (сервисы, использующие API системы и вот это вот всё)

как тогда правильно называетеся

Когда ты тестируешь два сервиса в связке

?

И как правильно называется тогда тестирование одного сервиса

дергая не по модулям, а уже в целом, пользуясь его API

?

Зы. Люди, где этому учат? В наше время в прокуренных и полуразрушенных помещениях мыхмата главных предметом был какой то матанализ с какими то там интегралами. Ага.

автоматизированное интеграционное тестирование стоит проводить об моки, а не об реальный сервис.

Вот собственно этого я и добивался.

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

Выполнение автоматизированных интеграционных тестов - это задача только Jenkins или другой системы непрерывной интеграции?

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

С реальными сервисами нужно проводить уже ручное тестирование и только после того как пройдут интеграционные тесты?

еще раз: интеграционные тесты проводятся с реальными сервисами. до этого проводится модульное тестирование своего кода. по очевидным причинам автоматизировать интеграционное тестирование - дорого, больно и что самое главное - не эффективно в 99% случаев

автоматическое интеграционное тестирование делается не об моки, а о реальный сервис

Афигеть. Я тестирую фунцкионал А, который использует Б, который еще не реализован. Каким образом я смогу простестировать это, не используя изоляцию (HTTP mocking)?

вообще для грамотного употребления терминов QA начни с http://www.bystqb.org/images/stories/ISTQB_Glossary_Russian_v2.3.pdf

твой вопрос начинается с определения что из себя представляет твоя система. если упомянутый API для конечного пользователя, а не часть системы, то «Когда ты тестируешь два сервиса в связке» - интеграционное , а «дергая не по модулям, а уже в целом, пользуясь его API» - системное либо системное интеграционное в зависимости от кейсов. если же ни один из сервисов не торчит наружу для конечного пользователя, то все проверки взаимодействия между ними - интеграционное тестирование

дочитай до конца, а потом переходи к вопросу. и да, модульного тестирования моков никто не отменял, если что.

У меня в папке

tests/integration

интеграционные тесты. Ищи примеры на гихабе. Даже у нашего консультатнта это есть. Миллион мух ошибается, а мы правы.

а теперь объясни зачем вам папка tests/integration. интеграцию с чем они проверяют?
с активно разрабатываемой функциональностью, к которой нет требований? тогда они будут падать постоянно и вы будете тратить кучу времени на поддержку тестов.
с активно разрабатываемой функциональностью, которая реализует описанный API? тогда зачем вам интегрироваться с ненаписанным кодом, если можно сразу интегрироваться с API?
с готовым сервисом? тогда зачем вам затягивать проверки если вы можете использовать моки, повторяющие поведение API?

Я тестирую фунцкионал А, который использует Б, который еще не реализован.

и да, это - не интеграционное тестирование. это модульное тестирование А.

Что тестируется в модульном тестировании?

Отдельные фукции классов/модулей. С помощью стабов мы говорим там: а как будет вести тестируемый метод, если метод запроса к чему-то там (файловая система, база данных ...) вернет что-то там.

А теперь если мы тестируем фунционал всего сервиса, то нам прийдется запускать серверный процесс. И делать вызовы уже API.

В этом случае вы вынуждены делать мокирования, но на новом уровне: mocked file system, in-memory database. Вынуждены потому, что на Jenkins сервере ты эту хрень не установишь.

Так в какую папочку мне кидать последнии тесты?

с активно разрабатываемой функциональностью, к которой нет требований?

требования уже есть.

тогда они будут падать постоянно

почему они обязаны будут падать? В чем прицина падения?

и вы будете тратить кучу времени на поддержку тестов

Это не является следсвием предыдущего пункта. Это свойства любых тестов. Их нужно всегда поддерживать.

Если это кому-то не нравится - пусть не пишет ни юнит тесты, ни какие либо еще.

Кстати, раз ты у нас спец в тестировании, прокомментируй вот этот график

Что тестируется в модульном тестировании? Отдельные фукции классов/модулей.

вообще-то нет. теоретически в модульном тестировании тестируются модули, которые по все тому же IEE - наименьшая часть системы, которая может быть протестирована отдельно, и зависит эта возможность от используемого тестового фреймворка. условно говоря, если у тебя из инструментов только вебдрайвер - то твоим модулем в каноничьном примере будет html форма логина в связке с php обработчиком, таблицей в биде и сервером, который всё это хостит. если же у тебя есть phpunit , то твоим модулем будет функция которая принимает данные, функция которая запрашивает данные из биде и так далее.

С помощью стабов мы говорим там: а как будет вести тестируемый метод, если метод запроса к чему-то там (файловая система, база данных ...) вернет что-то там.

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

А теперь если мы тестируем фунционал всего сервиса, то нам прийдется запускать серверный процесс. И делать вызовы уже API.

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

В этом случае вы вынуждены делать мокирования, но на новом уровне: mocked file system, in-memory database.

breaking news: когда начинаешь тестировать на новом уровне - моки тоже делаются на новом уровне

Вынуждены потому, что на Jenkins сервере ты эту хрень не установишь.

что ты несешь? при чем тут женкинс? женкинс - это примитивная запускалка задач. что ты ему скажешь - то он и запустит.

Так в какую папочку мне кидать последнии тесты?

в корзину. ты все равно не умеешь ими пользоваться

что ты несешь? при чем тут женкинс? женкинс - это примитивная запускалка задач. что ты ему скажешь - то он и запустит

jenkins запускает тесты,когда я делаю коммит. Не?

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

в корзину. ты все равно не умеешь ими пользоваться

Он тоже не умеет их писать,да?

это тоже не интеграционный тест? А какой тогда?

хватит путать unit test'ы в контексте ЯП (в котором у тебя есть инструменты для проверки сколь угодно малых кусков кода) и в контексте тестирования (где инструменты могут быть разными). в тестировании весь этот лимп бизкит с red light - green light не используется.
твой график же про test driven *development*, не про QA

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

Але гараж: если изменится реализация сервиса Б, то должны быть изменены все сервисы, которые его ипользуют (в данном случае - это А).

Что для этого нам нужно сделать? Изменить в интеграционных тестах все nock-и. ОК, наши интеграционные тесты должны быть по идее красными, меняем в А то, что исползует Б - тесты зеленые.

Теперь наши тесты доказывают-документируют, то что А может использовать новый Б. Для этого не нужно запускать Б. Мы, как в юнит тестах, не тестируем А и Б, мы тестируем А, использующий Б.

простите, а где вы видели тег QA в вопросе? Или я опять не на ту конференцию зашел?

https://gist.github.com/MikeBild/031e88dd5af0d5c9f9b2

чисто модульный тест, проверяющий функциональность модуля «сервер». то, что его назвали интеграционным - от того, что называли его дятлы, для которых все, что выходит за рамки проверки одной-единственной функции - интеграционные тесты.

Але гараж: если изменится реализация сервиса Б, то должны быть изменены все сервисы, которые его ипользуют (в данном случае - это А).

и изменится она тыщщу раз еще. поэтому о требованиях и договариваются до того, как писать реализацию

а чем тогда отличается тесты с запуском сервера (как по ссылке) от тестирования каждой фунцкии модуля?

я увидел тег «тестирование» и тред, в котором речь шла как раз о терминах тестирования.

я вот совершенно не понимаю, как это человеку, который путает Канта с Шопенгауэром, доверили командовать дивизией. люди, которые понятия не имеют о даже терминологии тестирования, изобретают свои особенные определения интеграционных тестов, после чего всех им впаривают. интеграционные тесты проверяют *интеграцию*, а 90% разработчиков до сих пор уверены, что интеграционный тест - это тест, в котором задействовано больше двух методов кода.

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

т.е. даже когда я буду вызывать 2 -3 ендпоинта, а сам «server» будет состоять из нескольких «модулей», да?

а 90% разработчиков до сих пор уверены, что интеграционный тест - это тест, в котором задействовано больше двух методов кода

т.е. и это тоже юнит-тесты, они же модульные тесты?

нет, да

вообще везде, где я работал, отделяли «юнит-тесты» как термин, используемыми разработчиками для тестов на классы и функции, от «модульных тестов» в терминологии QA, для тестов на изолированную часть системы, это хоть как-то устраняло путаницу. жаль, с интеграционными такое не прокатит

так в точки зрения разработчика что идет после юнит тестов?

Почему тогда википедия и некоторые люди ставят знак равенства между Unit-testing и модульным тестированием?

Значит нужно переводить «Unit Testing» как «Автономное тестирование»?

так в точки зрения разработчика что идет после юнит тестов?

С точки зрения разработчика после юнит-тестов жизни нет) тестировщики разберутся

Почему тогда википедия и некоторые люди ставят знак равенства между Unit-testing и модульным тестированием?

википедия прямо признается, что пишет о юнит-тестах в разработке, а не тестировании, никакого противоречия

Значит нужно переводить «Unit Testing» как «Автономное тестирование»?

Есть термин «компонентное тестирование» для qa, но для повседневного общения он не очень. Но в живом общении я вообще не слышал чтобы програмерский термин юнит-тесты употребляли в переводе

jenkins запускает тесты,когда я делаю коммит. Не?

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

Ты:

при чем тут женкинс?

Я:

В этом случае вы вынуждены делать мокирования, но на новом уровне: mocked file system, in-memory database.

Вынуждены потому, что на Jenkins сервере ты эту хрень не установишь

запуская тесты на локальной дев-машине, ты можешь делать все, что угодно (sudo, ставить базы).

На сервере, где работает Jenkins ты не установишь ни CouchDB, ни MongoDB, ни Oracle, ни MySQL.

Зы. Кастую в тред специалистов по юнит тестам.