Что даёт статика? Сверяем модель в коде с моделью в тестах: неиспользуемые селекторы, дубли, недостижимые шаги и т.д. Это про полноту и доверие к тестам.
А что по динамике? Показывает, что реально отрисовано и пройдено: экраны/страницы, использованные селекторы, маршруты/события. Да, мы ограничены набором сценариев, но это нормально: это наблюдение за выполнением сценариев, а не теоретическое покрытие.
Вывод простой - обе методологии нужно использовать, но у них разные цели Статика - доверие к тестам Динамика - эффективность тестов
В дополнение есть shift right практика, когда оценивается usage-based coverage. Собираем с прода данные по реально выполняемым сценариям/маршрутам, чтобы понять какие из них уже не актуальны и какие не покрыты.
Gariks дал хорошие рекомендации и мы немного подискутировали в комментариях к анонсу этой статьи в tg - https://t.me/latech/1113 Речь о книге Хононова - Изучаем DDD. Gariks привел схему из нее где отражено как выбор паттерна архитектуры влияет на выбор стратегии тестирования. Для примера можно взять две архитектуры по краям - Транзакционая и Событийная: В транзакционной мы предполагаем линейный код, который будет выполнять бизнес-логику шаг за шагом. Это значит, что вся сложность будет сосредоточена в последовательнастях вызовов методов, которые выполняют сценарии. Соотвественно наша стратегия тестирования - перевернутая пирамида, так как логика сильно связанная- отсюда преимущественно сквозные сценарии. В событийной мы сосредотачиваем бизнес-логику в обработчиках событий и агрегатах. Эти обработчики и агрегаты можно с легкостью тестировать изолированно. Отсюда акцент на юнит-тестах. В тоже время нас интересует интеграция с управляемыми зависимостями для тестирования потока событий. И тогда для e2e остается совсем немного места - ведь мы уже почти все проверили на уровнях ниже. В итоге получается классическая пирамида.
Спасибо за столь развернутый комментарий. Мне даже сложно что-то добавить, так как я придерживаюсь схожей позиции. Вопрос (мысли вслух) в том какая стратегия будет достижима, погрузить разработчиков в практики тестирования или погрузить QA в практики разработки. Меч обоюдоострый, потому к этому стоит подходить с осторожностью.
Спасибо за подробное описание. У нас есть сервисы где команды решили пойти по этому пути и успешно пользуются этим DSL. Этот подход предполагает хранение "коллекций запросов" в репозитории приложения. Postman же предлагает решение с централизованным хранилищем, которое в довесок включает в себя пространства команд и другие плюшки (например, генерация коллекций по сваггеру). У нас львиная доля работы с Postman - это межсервисные флоу, потому когда-то его и выбрали. Чтобы достичь того же с решением JetBrains, нужно создать единый репозиторий и поддерживать его. Теперь, конечно, это касается и Postman. Но есть еще один важный момент - чтобы перейти на решение JetBrains, нужно переписать все коллекции. Зачем, если следующий шаг будет тот же?
Статика или динамика - некорректный вопрос.
Что даёт статика?
Сверяем модель в коде с моделью в тестах: неиспользуемые селекторы, дубли, недостижимые шаги и т.д. Это про полноту и доверие к тестам.
А что по динамике?
Показывает, что реально отрисовано и пройдено: экраны/страницы, использованные селекторы, маршруты/события. Да, мы ограничены набором сценариев, но это нормально: это наблюдение за выполнением сценариев, а не теоретическое покрытие.
Вывод простой - обе методологии нужно использовать, но у них разные цели
Статика - доверие к тестам
Динамика - эффективность тестов
В дополнение есть shift right практика, когда оценивается usage-based coverage. Собираем с прода данные по реально выполняемым сценариям/маршрутам, чтобы понять какие из них уже не актуальны и какие не покрыты.
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, а это в больших компаниях зачастую является требованием для безопасности.
Тем не менее, сценарий теста, конфигурация моков и фикстуры описываются именно на языке разметки.