Gariks дал хорошие рекомендации и мы немного подискутировали в комментариях к анонсу этой статьи в tg - https://t.me/latech/1113 Речь о книге Хононова - Изучаем DDD. Gariks привел схему из нее где отражено как выбор паттерна архитектуры влияет на выбор стратегии тестирования. Для примера можно взять две архитектуры по краям - Транзакционая и Событийная: В транзакционной мы предполагаем линейный код, который будет выполнять бизнес-логику шаг за шагом. Это значит, что вся сложность будет сосредоточена в последовательнастях вызовов методов, которые выполняют сценарии. Соотвественно наша стратегия тестирования - перевернутая пирамида, так как логика сильно связанная- отсюда преимущественно сквозные сценарии. В событийной мы сосредотачиваем бизнес-логику в обработчиках событий и агрегатах. Эти обработчики и агрегаты можно с легкостью тестировать изолированно. Отсюда акцент на юнит-тестах. В тоже время нас интересует интеграция с управляемыми зависимостями для тестирования потока событий. И тогда для e2e остается совсем немного места - ведь мы уже почти все проверили на уровнях ниже. В итоге получается классическая пирамида.
Спасибо за столь развернутый комментарий. Мне даже сложно что-то добавить, так как я придерживаюсь схожей позиции. Вопрос (мысли вслух) в том какая стратегия будет достижима, погрузить разработчиков в практики тестирования или погрузить QA в практики разработки. Меч обоюдоострый, потому к этому стоит подходить с осторожностью.
Спасибо за подробное описание. У нас есть сервисы где команды решили пойти по этому пути и успешно пользуются этим DSL. Этот подход предполагает хранение "коллекций запросов" в репозитории приложения. Postman же предлагает решение с централизованным хранилищем, которое в довесок включает в себя пространства команд и другие плюшки (например, генерация коллекций по сваггеру). У нас львиная доля работы с Postman - это межсервисные флоу, потому когда-то его и выбрали. Чтобы достичь того же с решением JetBrains, нужно создать единый репозиторий и поддерживать его. Теперь, конечно, это касается и Postman. Но есть еще один важный момент - чтобы перейти на решение JetBrains, нужно переписать все коллекции. Зачем, если следующий шаг будет тот же?
Gariks дал хорошие рекомендации и мы немного подискутировали в комментариях к анонсу этой статьи в tg - https://t.me/latech/1113
Речь о книге Хононова - Изучаем DDD. Gariks привел схему из нее где отражено как выбор паттерна архитектуры влияет на выбор стратегии тестирования.
Для примера можно взять две архитектуры по краям - Транзакционая и Событийная:
В транзакционной мы предполагаем линейный код, который будет выполнять бизнес-логику шаг за шагом. Это значит, что вся сложность будет сосредоточена в последовательнастях вызовов методов, которые выполняют сценарии. Соотвественно наша стратегия тестирования - перевернутая пирамида, так как логика сильно связанная- отсюда преимущественно сквозные сценарии.
В событийной мы сосредотачиваем бизнес-логику в обработчиках событий и агрегатах. Эти обработчики и агрегаты можно с легкостью тестировать изолированно. Отсюда акцент на юнит-тестах. В тоже время нас интересует интеграция с управляемыми зависимостями для тестирования потока событий. И тогда для e2e остается совсем немного места - ведь мы уже почти все проверили на уровнях ниже. В итоге получается классическая пирамида.
Если говорить о реализации самой пирамиды, то есть множество статей разного уровня погружения. На вскидку, обзорная (в ней так же есть ссылки на др ресурсы) - https://medium.com/@mateuszroth/why-the-test-pyramid-is-a-bullshit-guide-to-testing-towards-modern-frontend-and-backend-apps-4246e89b87bd
Это ошибка - прошу меня простить)
Спасибо за столь развернутый комментарий.
Мне даже сложно что-то добавить, так как я придерживаюсь схожей позиции.
Вопрос (мысли вслух) в том какая стратегия будет достижима, погрузить разработчиков в практики тестирования или погрузить QA в практики разработки. Меч обоюдоострый, потому к этому стоит подходить с осторожностью.
Спасибо за подробное описание. У нас есть сервисы где команды решили пойти по этому пути и успешно пользуются этим DSL.
Этот подход предполагает хранение "коллекций запросов" в репозитории приложения. Postman же предлагает решение с централизованным хранилищем, которое в довесок включает в себя пространства команд и другие плюшки (например, генерация коллекций по сваггеру).
У нас львиная доля работы с Postman - это межсервисные флоу, потому когда-то его и выбрали. Чтобы достичь того же с решением JetBrains, нужно создать единый репозиторий и поддерживать его. Теперь, конечно, это касается и Postman.
Но есть еще один важный момент - чтобы перейти на решение JetBrains, нужно переписать все коллекции. Зачем, если следующий шаг будет тот же?
У Insomnia нет SSO, а это в больших компаниях зачастую является требованием для безопасности.
Тем не менее, сценарий теста, конфигурация моков и фикстуры описываются именно на языке разметки.