Сам метод инициализации через ==? не потокобезопасный
Да, вы правы, желательно метод инициализации хотя бы в один lock() обернуть. Мы, на своих проектах, это делаем. В данной статье это опустил, дабы не усложнять повествование.
если мы хотим их вызвать за пределами тестов
Конструкцию "container.Register()" не обязательно вызывать один раз. Это можно сделать сколько угодно раз.
По идее, в проекте каждого сервиса/сервисов должен быть свой класс Installer'а. То есть класс, в котором будет описано, как именно устанавливать сервис, и наличие каких зависимостей стоит проверить в подаваемом на вход контейнере, перед вызовом "container.Register()".
В итоге, ContainerInitializer.InitContainer() из статьи, будет представлять из себя перечисление всех тех инсталлеров, которые нужны тестовому проекту.
Такой подход позволит переиспользовать классы Installer'ов где угодно.
Мы, например, переиспользуем одни и те же инсталлеры, вместе с разработчиками, просто обмениваясь nuget-пакетами с описанием контрактов взаимодействия.
Тестировщики (SDET'ы) и пишут. Часто даже раньше, чем появятся реальные сервисы. TDD в действии так сказать)
Деплой, запуск и публикация результатов в AzureDevops.
Да, и сборки и деплой - все в Azure DevOps. Только не "Pipelines -> Releases", а "Pipelines -> Pipelines". Мы придерживаемся подхода Infrastructure as code, потому все пайплайны описаны в коде, в yaml-файлах (azure yaml pipelines). Нам их вполне хватает, не хочется руками Release настраивать.
В целом, в части azure yaml pipelines, тоже есть что полезного рассказать. Как-нибудь расскажу. Но это вполне тянет на отдельную статью.
В свое время, рассматривали несколько инструментов для нагрузочного тестирования, и смотрели и на Locust в том числе. Может, конечно, за три года что-то поменялось, и Locust стал совсем другим, но, раньше было так: В принципе Locust неплох, особенно для тех кому Python роднее. Что-то может, и в конфигурации из нескольких slave-нод даже способен выдать некоторую нагрузку.
Но он проигрывает gatling'у по многим параметрам. Например: - Отчетность. Locust'у нужно хостить отдельный сайт для результатов теста, да и тот не особо информативен. У Gatling'а отчет html-файлом и там есть все что нужно. - Сценарии нагрузки. Locust может только нагружать только линейно ("лесенкой"). У gatling'a очень много вариантов регулировки сценариев. - Мощность / потребление ресурсов. Тут думаю особо не нужно даже комментировать. В гонке за тем "кто меньше съест CPU и памяти", gatling'у разве что k6.go способен составить конкуренцию (недавно на хабре была статья-сравнение). - Протоколы. Не уверен, что Locust может нагружать gRPC, AMQP, JDBC и kafka. Про то, как это сделать в gatling - ребята скоро напишут)
Ммм... в Picatinny появился Hashicorp Vault !!!. Не знал. Это хорошая новость. Значит все-таки придется его себе затащить. Волт нам нужен ))
Еще, было бы классно, если бы можно было скачать готовый bundle, в котором уже есть Picatinny. По аналогии с gatling-bundle.
Имхо, для нового человека, работа с бандлом все-таки несколько проще чем поставить sbt, idea + sbt plugin в нее, и запустить генерацию g8.template. Легче просто скачать бандл по ссылке. В нем уже есть готовые батники/шелл скрипты для запуска + все необходимые библиотеки уже на месте. И поправить скрипты можно хоть в блокноте.
А уже позже, как проникнется, можно и остальное сделать.
Не совсем понял как вы сопоставляете клики реальных пользователей с кликами из тестов? (Пример про непокрытые тестами виджеты). Тесты ведь на дев средах, а пользователи - на проде. Или у вас GA / яндекс.метрики собираются со всех сред сразу?
А не могли бы вы поделиться опытом? Всегда было интересно, чем же таким в сфере ИТ надо заниматься, чтобы и в возрасте «за 50» зарабатывать себе на хлеб, работая в ИТ-сфере.
Спасибо за совет. Соглашусь. Поменял)
Да, вы правы, желательно метод инициализации хотя бы в один lock() обернуть. Мы, на своих проектах, это делаем. В данной статье это опустил, дабы не усложнять повествование.
Конструкцию "container.Register()" не обязательно вызывать один раз. Это можно сделать сколько угодно раз.
По идее, в проекте каждого сервиса/сервисов должен быть свой класс Installer'а. То есть класс, в котором будет описано, как именно устанавливать сервис, и наличие каких зависимостей стоит проверить в подаваемом на вход контейнере, перед вызовом "container.Register()".
В итоге, ContainerInitializer.InitContainer() из статьи, будет представлять из себя перечисление всех тех инсталлеров, которые нужны тестовому проекту.
Такой подход позволит переиспользовать классы Installer'ов где угодно.
Мы, например, переиспользуем одни и те же инсталлеры, вместе с разработчиками, просто обмениваясь nuget-пакетами с описанием контрактов взаимодействия.
InMemory конечно хорошо. Но, на практике - не всегда возможно.
Пример как раз про то, когда нужна "реальная".
1.
Кто у вас пишет Моки для сервисов?Тестировщики (SDET'ы) и пишут. Часто даже раньше, чем появятся реальные сервисы. TDD в действии так сказать)
Деплой, запуск и публикация результатов в AzureDevops.Да, и сборки и деплой - все в Azure DevOps. Только не "Pipelines -> Releases", а "Pipelines -> Pipelines". Мы придерживаемся подхода Infrastructure as code, потому все пайплайны описаны в коде, в yaml-файлах (azure yaml pipelines). Нам их вполне хватает, не хочется руками Release настраивать.
В целом, в части azure yaml pipelines, тоже есть что полезного рассказать. Как-нибудь расскажу. Но это вполне тянет на отдельную статью.
А, скрин... да пожалуйста)
В свое время, рассматривали несколько инструментов для нагрузочного тестирования, и смотрели и на Locust в том числе.
Может, конечно, за три года что-то поменялось, и Locust стал совсем другим, но, раньше было так:
В принципе Locust неплох, особенно для тех кому Python роднее. Что-то может, и в конфигурации из нескольких slave-нод даже способен выдать некоторую нагрузку.
Но он проигрывает gatling'у по многим параметрам. Например:
- Отчетность. Locust'у нужно хостить отдельный сайт для результатов теста, да и тот не особо информативен. У Gatling'а отчет html-файлом и там есть все что нужно.
- Сценарии нагрузки. Locust может только нагружать только линейно ("лесенкой"). У gatling'a очень много вариантов регулировки сценариев.
- Мощность / потребление ресурсов. Тут думаю особо не нужно даже комментировать. В гонке за тем "кто меньше съест CPU и памяти", gatling'у разве что k6.go способен составить конкуренцию (недавно на хабре была статья-сравнение).
- Протоколы. Не уверен, что Locust может нагружать gRPC, AMQP, JDBC и kafka. Про то, как это сделать в gatling - ребята скоро напишут)
Ммм... в Picatinny появился Hashicorp Vault !!!. Не знал. Это хорошая новость. Значит все-таки придется его себе затащить. Волт нам нужен ))
Еще, было бы классно, если бы можно было скачать готовый bundle, в котором уже есть Picatinny. По аналогии с gatling-bundle.
Имхо, для нового человека, работа с бандлом все-таки несколько проще чем поставить sbt, idea + sbt plugin в нее, и запустить генерацию g8.template. Легче просто скачать бандл по ссылке. В нем уже есть готовые батники/шелл скрипты для запуска + все необходимые библиотеки уже на месте. И поправить скрипты можно хоть в блокноте.
А уже позже, как проникнется, можно и остальное сделать.
Не совсем понял как вы сопоставляете клики реальных пользователей с кликами из тестов? (Пример про непокрытые тестами виджеты). Тесты ведь на дев средах, а пользователи - на проде. Или у вас GA / яндекс.метрики собираются со всех сред сразу?
А не могли бы вы поделиться опытом? Всегда было интересно, чем же таким в сфере ИТ надо заниматься, чтобы и в возрасте «за 50» зарабатывать себе на хлеб, работая в ИТ-сфере.
На сайт и телеграм канал «saverudata» загляните. Там прям форму проверки сделали.