> какая моделька хранится в самой базе... get запрос и проверить, что сервис вернул верный ответ
1) Не всегда для запросов меняющих состояние, есть запросы позволяющие определить, поменялось ли состояние или это весьма сложно сделать, поэтому рано или поздно придется идти в базу, если нужно будет проверить изменения.
2) Есть множество случаев, когда для вызова того или иного метода требуется определенное состояние в базе, его можно добиться вызовом методов, но иногда это превращается в очень много предварительных шагов, получается проще - получить нужное состояние просто инициализировав его напрямую в базе.
> пометить атрибутом [BeforeScenario]
Можно, но тут используется XUnit, его разработчики против таких атрибутов и подхода, максимум можно вынести его в конструктор BaseFixture. А в других тестовых фреймворках - пожалуйста.
> WebApplicationFactory ... Т.е. вы тестируете не тот код, который в проекте сейчас, а тот, который упакован в контейнер .
В этом и суть компонентных тестов, чтобы тестировать максимально приближенно к реальным условиям.
> ci не прошёл и не упаковал контейнер ты же не провериш
Там мультестейдженговый dockerfile, все собирается локально, не нужно ничего ждать.
> А удобно ли это дебажить
По поводу проверки и дебага - docker-compose up, затем стопаете сервис app и дебажите локально в своей IDE. Почитайте в корне репы файл readme.md.
> Я вижу что много работы делается руками. Вы не думали делать её из кода
Для меня docker-compose + dockerfile вполне себе код. А Если Вы о различных абстрацииях для того же docker из .Net, ну для меня проще и понятней именно вышеупомятнутая связка. И можно всегда к DevOps обратиться за помощью.
А в CI есть подход docker in docker - он отлично справляется с запуском docker-compose.
> интересно, что такое здесь Scoped?
В конкретно этих тестах, да, можно использовать и transient.
> А у вас эти тесты пишут только разработчики или тестировщики тоже
В командах/компаниях, где я принимал участие, только разработчиками, стезя тестировщиков была - e2e тестирование. Но за всех не скажу, возможно и тестировщики у нас где-то могут писать и Unit.
> Вы пробовали написать сложный сценарий из 10 шагов пользователя, к примеру. Как-то код тестов переиспользуется
На них можно прикрутить и spec flow, если Вы об этом. А так большое количество многоходовых сценариев (мое мнение) это уже больше к e2e тестам, но на прошлом месте я использовал компонентные тесты для проверки работы оркестратора саги, там да приходилось выносить отдельные шаги инициализации в другие методы и переиспользовать.
Мы в них обращаемся непосредственно базу данных и для каждого теста, почти всегда, требуется определенный набор данных или его отсутствие, поэтому и тесты запускаются последовательно. Конечно, можно запроектировать тесты так, чтобы они учитывали уже имеющиеся данные, но в поддержке такое поведение достаточно трудное и проще запускать их изолированно.
Есть мнение, что на такие виды тестов из-за сложности, не считают test code coverage. Т.е. компонентные тесты это не замена unit, в которых как раз отлично считается этот показатель, а некоторая надстройка, которая может дублировать, но не заменять white box тестирование.
Микросервисная архитектура разделяет приложение на несколько самостоятельных частей, узкое место каждой (база данных), не становится узким местом для всей системы.
И в вашей синтенции ошибка - "разные инстансы микросервисов", а нужно писать "разные инстансы микросервиса". База данных должна принадлежать, только одному микросервису, иначе это грубое нарушение проектирование такой архитектуры.
К присутствию на ремонте с мастером я отношусь также, как если бы со мной на моей работе присутствовал клиент и под руку говорил, как мне писать код. Ничего кроме раздражение от неспециалиста ждать не приходится.
Для меня хороший автосервис это корректно оформленные документы, юридическая гарантия, чистота в приемке. Все остальное - на свой страх и риск. То что вы говорите про "рынок продавца" это симптом жесткой экономии среди населения. Запись к официальному дилеру есть и условно "на завтрашний день", но цены в несколько раз выше, поэтому народ и голосует за "гараж дяди Васи".
Про тот же "Додо" почитайте тут на хабре - все в открытом доступе. Была запущена рекламная компания, которая стоила много и много денег. Но в ответственный момент, из-за наплыва пользователей платформа засбоила, что конечно не принесло радости "клиентам".
Есть машина, но я не пользуюсь сервисом уровня - "дядя Вася в гараже". Я принципиально обращаюсь в ремонт к тем, кто имеет уголок потребителя, сайт и т.д. А все остальное - уровень "бабок с семками" под мостом. Что-то случится с машиной после ремонта, а с исполнителя и взять нечего, поэтому и другим не советую такой "сервис". Но согласен есть исключение - в деревнях/селах, там все на виду, но и очень и очень редко даже ИП оформлено (по крайней мере я таких не встречал, все в "черную").
Сайт и т.д. не гарантия качества ремонта, но он показывает как владелец относится к своему бизнесу.
На мой взгляд, нужно везде искать компромисс. Между "сайтом-картинкой" и "навороченным мега порталом" есть очень много мест приемлемых для старта бизнеса. А вот то, что жадность мало когда "выстреливала", увы жизненных примеров куча.
Есть и другие примеры. Когда также была "картинка", а клиенты "поперли", но система просела из-за нагрузок и многие остались недовольны и ушли к конкурентам, т.к. там намного надежнее и стабильней.
В теоретическую часть я бы добавил обобщение саги с позиции микросервисов, и что они бывают хореографическими и оркестрируемыми. MT как раз используют оркестрацию.
От паттернов Requests отказались по соображением производительности, используем синхронный RPC через http/rest.
Плюс роутинг MTский по большей части руками настраиваем из-за соображений гетерогенных систем, когда разные микросервисы могут иметь разные языки реализации.
Скажем так, небо "будет портиться" и без спутников (см Light Pollution). Так что это только вопрос периода ожидания неизбежного.
Поэтому я считаю лукавством, притензии любителей к SL, т.к. никогда не слышал, о притензиях к властям, чего это так "хорошо стали светить на дорогах и дворах, т.к. это нам портит наблюдения". В "мрак", мало кто хочет возвратиться.
> какая моделька хранится в самой базе... get запрос и проверить, что сервис вернул верный ответ
1) Не всегда для запросов меняющих состояние, есть запросы позволяющие определить, поменялось ли состояние или это весьма сложно сделать, поэтому рано или поздно придется идти в базу, если нужно будет проверить изменения.
2) Есть множество случаев, когда для вызова того или иного метода требуется определенное состояние в базе, его можно добиться вызовом методов, но иногда это превращается в очень много предварительных шагов, получается проще - получить нужное состояние просто инициализировав его напрямую в базе.
> пометить атрибутом [BeforeScenario]
Можно, но тут используется XUnit, его разработчики против таких атрибутов и подхода, максимум можно вынести его в конструктор BaseFixture. А в других тестовых фреймворках - пожалуйста.
> WebApplicationFactory ... Т.е. вы тестируете не тот код, который в проекте сейчас, а тот, который упакован в контейнер .
В этом и суть компонентных тестов, чтобы тестировать максимально приближенно к реальным условиям.
> ci не прошёл и не упаковал контейнер ты же не провериш
Там мультестейдженговый dockerfile, все собирается локально, не нужно ничего ждать.
> А удобно ли это дебажить
По поводу проверки и дебага - docker-compose up, затем стопаете сервис app и дебажите локально в своей IDE. Почитайте в корне репы файл readme.md.
> Я вижу что много работы делается руками. Вы не думали делать её из кода
Для меня docker-compose + dockerfile вполне себе код. А Если Вы о различных абстрацииях для того же docker из .Net, ну для меня проще и понятней именно вышеупомятнутая связка. И можно всегда к DevOps обратиться за помощью.
А в CI есть подход docker in docker - он отлично справляется с запуском docker-compose.
> интересно, что такое здесь Scoped?
В конкретно этих тестах, да, можно использовать и transient.
> А у вас эти тесты пишут только разработчики или тестировщики тоже
В командах/компаниях, где я принимал участие, только разработчиками, стезя тестировщиков была - e2e тестирование. Но за всех не скажу, возможно и тестировщики у нас где-то могут писать и Unit.
> Вы пробовали написать сложный сценарий из 10 шагов пользователя, к примеру. Как-то код тестов переиспользуется
На них можно прикрутить и spec flow, если Вы об этом. А так большое количество многоходовых сценариев (мое мнение) это уже больше к e2e тестам, но на прошлом месте я использовал компонентные тесты для проверки работы оркестратора саги, там да приходилось выносить отдельные шаги инициализации в другие методы и переиспользовать.
Мы в них обращаемся непосредственно базу данных и для каждого теста, почти всегда, требуется определенный набор данных или его отсутствие, поэтому и тесты запускаются последовательно. Конечно, можно запроектировать тесты так, чтобы они учитывали уже имеющиеся данные, но в поддержке такое поведение достаточно трудное и проще запускать их изолированно.
Да, насчет замены e2e я описал - это не замена, а дополнение. Просто немного дешевле поддерживаемое.
Есть мнение, что на такие виды тестов из-за сложности, не считают test code coverage. Т.е. компонентные тесты это не замена unit, в которых как раз отлично считается этот показатель, а некоторая надстройка, которая может дублировать, но не заменять white box тестирование.
Микросервисная архитектура разделяет приложение на несколько самостоятельных частей, узкое место каждой (база данных), не становится узким местом для всей системы.
И в вашей синтенции ошибка - "разные инстансы микросервисов", а нужно писать "разные инстансы микросервиса". База данных должна принадлежать, только одному микросервису, иначе это грубое нарушение проектирование такой архитектуры.
а причем тут это? Я имел ввиду, что база данных в микросервисной архитектуре, далеко не узкое место.
Кубер это обычно микросервисы, а там у каждого своя база.
К присутствию на ремонте с мастером я отношусь также, как если бы со мной на моей работе присутствовал клиент и под руку говорил, как мне писать код. Ничего кроме раздражение от неспециалиста ждать не приходится.
Для меня хороший автосервис это корректно оформленные документы, юридическая гарантия, чистота в приемке. Все остальное - на свой страх и риск. То что вы говорите про "рынок продавца" это симптом жесткой экономии среди населения. Запись к официальному дилеру есть и условно "на завтрашний день", но цены в несколько раз выше, поэтому народ и голосует за "гараж дяди Васи".
Про тот же "Додо" почитайте тут на хабре - все в открытом доступе. Была запущена рекламная компания, которая стоила много и много денег. Но в ответственный момент, из-за наплыва пользователей платформа засбоила, что конечно не принесло радости "клиентам".
Есть машина, но я не пользуюсь сервисом уровня - "дядя Вася в гараже". Я принципиально обращаюсь в ремонт к тем, кто имеет уголок потребителя, сайт и т.д. А все остальное - уровень "бабок с семками" под мостом. Что-то случится с машиной после ремонта, а с исполнителя и взять нечего, поэтому и другим не советую такой "сервис". Но согласен есть исключение - в деревнях/селах, там все на виду, но и очень и очень редко даже ИП оформлено (по крайней мере я таких не встречал, все в "черную").
Сайт и т.д. не гарантия качества ремонта, но он показывает как владелец относится к своему бизнесу.
Сайт в мало мальски малом бизнесе услуг сейчас почти всегда есть. Это или авито/vk/insta или свой.
На мой взгляд, нужно везде искать компромисс. Между "сайтом-картинкой" и "навороченным мега порталом" есть очень много мест приемлемых для старта бизнеса. А вот то, что жадность мало когда "выстреливала", увы жизненных примеров куча.
Есть и другие примеры. Когда также была "картинка", а клиенты "поперли", но система просела из-за нагрузок и многие остались недовольны и ушли к конкурентам, т.к. там намного надежнее и стабильней.
Активно использую в своих проектах саги из MT.
В теоретическую часть я бы добавил обобщение саги с позиции микросервисов, и что они бывают хореографическими и оркестрируемыми. MT как раз используют оркестрацию.
От паттернов Requests отказались по соображением производительности, используем синхронный RPC через http/rest.
Плюс роутинг MTский по большей части руками настраиваем из-за соображений гетерогенных систем, когда разные микросервисы могут иметь разные языки реализации.
> подальше от города уже не поможет
Вы опять перегибаете палку. Трудность для астрофото!= трудность для визуала.
> а небо уже испортили
Скажем так, небо "будет портиться" и без спутников (см Light Pollution). Так что это только вопрос периода ожидания неизбежного.
Поэтому я считаю лукавством, притензии любителей к SL, т.к. никогда не слышал, о притензиях к властям, чего это так "хорошо стали светить на дорогах и дворах, т.к. это нам портит наблюдения". В "мрак", мало кто хочет возвратиться.
Ну не знаю - как отдавать свои перс данные левым людям у которых даже работать возможно не будешь.
За мой 15 летний стаж, СБ проверяла только после принятия оффера, непосредственно перед подписанием ТД.
А как насчет просьбы передачи паспортных данных до оффера? Сейчас встретился с таким.