Комментарии 14
Спасибо за статью.
Все тесты должен писать разработчик - это ваш специалист по коду. QA только приносят ему готовые спецификации\сценарии тестов - специалисты по качеству же. Вместе, вы как команда ответственные за качество продукта.
e2e тестирование тоже выполняется разработчиками. И вы правильно заметили, про скоуп по 1 сервису. Т.к. Ваши сервисы по умолчанию должны быть Независимыми - тестируются и деплоятся отдельно от остальных. А то чего вы на самом деле боитесь - интеграция сервисов, покрывается Контрактными Тестами.
Конечно у вас должны возникнуть вопросы к правильности архитектуры ваших сервисов, их границам.
Иначе, скорее всего у вас так, - у вас появятся огромные тестовые стенды с полным поднятым окружением. Еще хуже, когда их становится больше чем у вас команд.
Рекомендую к просмотру видео Dave Farley - соавтор методологии Continuous Delivery, а конкретно про e2e тестирование и Acceptance тестирование.
все должен делать разработчик, AQA не нужны, я верно понял?
Не верно. QA все так же нужны - их роль возвращается к их ключевой компетенции - они пишут тестовые сценарии, определяют классы эквивалентности, выполняют исследовательское тестирование, чтобы найти возможные косяки. Ревьювят тесты.
Все это добро они приносят разрабам. Разрабы это все кодируют - профит.
Конечно никто не запрещает QA писать код, если у них есть такой скил. Но это тоже должно быть правильно организовано. Все-таки разрабы больше знают про то как написать поддерживаемый код. Не каждый тестировщик этим интересуется.
Тут еще важно правильно организовать код и тесты в репе. Т.к. тесты ломаются когда меняется код. А код меняют разрабы. Значит им его и чинить. Иначе получается нездоровая динамика - сокрытие информации от разрабов, когда они не знают работает ли система, пока не запушат все и не увидят лампочку...
AQA - automatic quality assurance. Я имел ввиду тех, кто пишет автотесты
Понял. Ну как сказать... не все что делается - лучшая практика. Иногда это просто то что делают все...
ИМХО этот тайтл появился из-за размытия понятия QA, чтобы отделить мануальщиков, от автоматизаторов - не более. Чтобы было проще нанимать людей со скилом в программировании.
Тут срабатывает как раз тот вариант, когда QA могут писать Acceptance тесты, в репе с кодом. Но тут надо следить, чтобы QA соблюдали практики написания кода разработчиков (или если они более скиловые - предлагали свои). Но владение кодом должно быть общим и по большей части - у разрабов.
Это про то, что разрабы по итогу будут запускать эти тесты, чтобы понять все ли они правильно сделали. И если тест падает без очевидной причины - им надо разобраться в чем именно проблема.
Т.е. роль вполне себе актуальная.
Правда когда ее внедряют в Вотерфольных организациях это превращается в противоположность, когда QA отдельно и разрабы отдельно. Возвращаемся к вопросу о скорости фидбека.
Спасибо за столь развернутый комментарий.
Мне даже сложно что-то добавить, так как я придерживаюсь схожей позиции.
Вопрос (мысли вслух) в том какая стратегия будет достижима, погрузить разработчиков в практики тестирования или погрузить QA в практики разработки. Меч обоюдоострый, потому к этому стоит подходить с осторожностью.
Выбор стратегии тестирования пирамида, ромб или перевернутая зависит от архитектуры приложения, а выбор архитектуры приложения зависит от требований.
Например приложение может просто принимать строку на вход и на выходе выводить ее перевернутой, для такого приложения будет более уместна перевернутая пирамида тестирования.
Например если у вас «ЧА», одна модель хранения данных (например база данных) и вы используете ORM, ромб это ваш выбор, потому что писать unit тесты c active record не целесообразно, а интеграционные в самый раз.
По поводу интеграционных тестов и моков, существуют понятия процессные зависимости и внепроцессные зависмости.
Все внепроцессные зависимости делятся на две категории.
Управляемые зависимости (внепроцессные зависимости, находящиеся под вашим полным контролем): эти зависимости доступны только через ваше приложение; взаимодействия с ними не видны внешнему миру. Типичный пример — база данных.
Неуправляемые зависимости (внепроцессные зависимости, которые не находятся под вашим полным контролем) — результат взаимодействия с такими зависимостями виден извне. В качестве примеров можно привести сервер SMTP и шину сообщений.
Взаимодействия с управляемыми зависимостями относятся к деталям имплементации. И наоборот, взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения вашей системы.
Это различие приводит к тому, что такие зависимости по‑разному обрабатываются в интеграционных тестах. Взаимодействия с управляемыми зависимостями являются деталями имплементации. Использовать их следует в исходном виде в интеграционных тестах. Взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения системы. Такие зависимости должны заменяться моками.
Я полностью согласен с @Atorian— тесты должны писать разработчики
Благодарю за содержательный комментарий, про "ромб" прям интересно. А не подскажете, где можно про перечисленные вами стратегии тестирования "ромб", "пирамида" и "перевёрнутая пирамида" и их связь с архитектурой приложения более подробно почитать?
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
Непонятно, почему приемочные (acceptance bdd) тесты находятся ближе к основанию пирамиды, чем интеграционные. По идее они менее гранулярные.
Давайте распутаем. Есть два типа стейкхолдеров в ИТ. Продуктовые знают Что, но не знают Как. Инженерные знают Как но не знают Что. Ни первые ни вторые не любят погружаться в домены друг друга. Отсюда два вывода.
1. Каждый тестирует свой домен - инженеры что накодили, продакты что напридумали.
2. Продакты не умеют автоматизировать свои тесты, поэтому мы их либо учим клик-инструментам, либо даём личного автоматизатора.
Соответственно, инженера стремятся к 100% покрытия ими накоженного, а продакты стремятся к 100% покрытия ими напридуманного. Так как накоженное часто не совпадает с напридуманным, некоторое дублирование покрытия тестами лучше дырок в нем.
К сожалению все чаще сталкиваюсь с коллегами которые считают что unit тесты не нужны, чистый код и архитектура это пережиток прошлого и наследие дедов, сейчас все иначе... и т.д. Из-за своих софт-скиллов не вступаю в спор, но мне страшно за будущее разработки, так как это мне говорили TL и синьоры... Да даже тут на хабре в комментариях бывают пришут.
КМК нужно на собеседованиях ставить акцент не на алгоритмы, а на архитектуру, профессионализм, кругозор, знание минусов и плюсов различных методик и подходов. Так как это напрямую влияет на сопровождаемость и развитие продукта!
Пирамида тестирования VS чистая архитектура — делим тесты между QA и разработчиком