Как стать автором
Обновить

Ночь. Облако. Дебаг. Прокся, или Как мы все вылечили, развернув L2-тесты в Kubernetes

Уровень сложностиСредний
Время на прочтение17 мин
Количество просмотров2.8K
Всего голосов 18: ↑18 и ↓0+18
Комментарии5

Комментарии 5

Спасибо, полезно! И за опыт и за ссылки.

Спасибо.
1. Кто у вас пишет Моки для сервисов?
2. Деплой, запуск и публикация результатов в AzureDevops.
Хорошо бы пару реальных скринов из Pipelines -> Releases увидеть.
У вас там деплой и запуск тестов происходит?

1. Кто у вас пишет Моки для сервисов?

Тестировщики (SDET'ы) и пишут. Часто даже раньше, чем появятся реальные сервисы. TDD в действии так сказать)

  1. Деплой, запуск и публикация результатов в AzureDevops.

Да, и сборки и деплой - все в Azure DevOps. Только не "Pipelines -> Releases", а "Pipelines -> Pipelines". Мы придерживаемся подхода Infrastructure as code, потому все пайплайны описаны в коде, в yaml-файлах (azure yaml pipelines). Нам их вполне хватает, не хочется руками Release настраивать.

В целом, в части azure yaml pipelines, тоже есть что полезного рассказать. Как-нибудь расскажу. Но это вполне тянет на отдельную статью.

А, скрин... да пожалуйста)

Весьма содержательная статья, благодарствую!

Не даны даже короткие но чёткие определения L1, L2, L3, что вообще вы под ними понимаете. Из описания абсолютно непонятно в чём отличие между ними.

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

Суть статьи сводится к рассказу о том, что моки это круто и как вы научились их использовать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий