Небольшие тесты могут быть удивительно мощными в автоматизации тестирования, особенно по сравнению с большими e2e-тестами. Сквозное тестирование, хотя и имеет неоценимое значение для достижения нужного покрытия, часто имеет существенные недостатки. Такие тесты, как правило, медленные, подвержены ошибкам и часто создают узкие места при масштабировании. Чтобы повысить производительность, надежность и масштабируемость, необходимо выйти за рамки ограничений. Одно из решений — переход к более мелким и направленным тестам.
Атомарные тесты, которые отличаются направленным подходом и изолированной областью тестирования, могут решить проблему ограничений сквозных тестов, сохраняя при этом их преимущества. Но прежде чем углубимся в тему, давайте подробнее рассмотрим проблемы.
Проблемы сквозных тестов
End-to-end-тесты полезны для моделирования реальных пользовательских сценариев, в первую очередь через пользовательский интерфейс, для проверки всего процесса работы приложения от начала до конца. Тестирование приложения через GUI неоценимо для обеспечения правильной работы всех компонентов и зависимостей. Однако автоматизация сквозных тестов весьма проблематична как раз из-за их чрезмерной зависимости от пользовательского интерфейса.
Каждое дополнительное взаимодействие с пользовательским интерфейсом увеличивает сложность теста и вероятность возникновения ошибки. Эти ошибки могут быть вызваны различными факторами, например динамическое содержимое страницы, проблемы с синхронизацией и таймингами, непредсказуемые внутренние и внешние зависимости. Проще говоря, чем больше сквозной тест, тем выше вероятность его «поломки».
Вероятность ошибок также усугубляется другими распространенными проблемами. Ниже мы рассмотрим три ключевые проблемы, которые могут решить атомарные тесты, на примере теста, добавляющего товар в корзину в приложении интернет-магазина:
- Длительное время выполнения: сквозные тесты часто занимают много времени из-за того, что охватывают весь поток приложения. В приведенном ниже примере должен быть пройден каждый шаг в потоке (синие поля) для выполнения ключевых действий и проверок (оранжевые поля) в тесте AddItemToCart. То есть ключевыми шагами теста являются добавление в корзину и проверка корзины, но мы не можем добавить товар, пока не войдем в систему, затем выполним поиск и выберем продукт. Этот длинный процесс существенно увеличивает общее время выполнения теста.
Сквозной тест: большие рабочие процессы увеличивают время выполнения.
- Чувствительность к любым изменениям: Сквозные потоки могут быть весьма чувствительны к изменениям даже в одной точке, что часто «обрушивает» всю цепочку шагов. Например, сбой теста на шаге ‘Select Product’ не позволит выполнить следующие — ключевые — шаги теста. Это делает тест нестабильным и склонным к ложноотрицательным результатам.
Сквозной тест: Изменения в одной области приложения могут повлиять на весь тест.
- Недостаток независимости: Часто в нескольких сквозных тестах есть общие для них шаги, что может привести к многочисленным сбоям всех этих тестов. Например, сбой теста на общем для всех шаге ‘Select Product’ приведет не только к сбою AddItemToCart, но и к сбою не связанных с ним тестов. Это создает «излишний шум», мешает определять источники проблем.
Сквозной тест: Сбои на общих этапах часто приводят к ошибкам в нескольких тестах.
Подводя итог, можно сказать, что сквозные тесты имеют большую площадь взаимодействия с пользовательским интерфейсом, что приводит к тому, что тесты выполняются медленнее, более склонны к сбоям и часто дают неправильные результаты. Хотя эти тесты нужны для верификации функциональности, они требуют баланса между покрытием и надежностью. Теперь разберемся, как атомарные тесты помогают достичь этого баланса.
Одно из решений — атомарность
Атомарные тесты — это «сфокусированные» тесты, которые охватывают очень небольшую часть приложения. Термин «атомарный» здесь подразумевает наименьшую единицу теста, пригодную для проверки части функциональности. Атомарные тесты в некотором роде противоположны сквозным тестам; атомарные тесты создаются так, чтобы быть ориентированными на однозадачность, изоляцию и независимость.
Эти три принципа можно рассматривать как основные для разработки атомарных тестов, но конкретные методы их реализации могут быть разными, включая использование сессионных cookies, javascript-функций браузера, API-вызовов приложения, и операций с бэкэндом/базами данных. Давайте подробнее рассмотрим эти принципы на примере предыдущего AddItemToCart:
- Сфокусированная функциональность: Каждый тест должен быть изолированным и ограниченным по области, проверять только ограниченную функциональность. Например, тест AddItemToCart должен быть ограничен только ключевыми действиями и валидациями, максимально изолируясь от любых других действий. Это должно повысить эффективность.
Атомарный тест должен быть изолирован, проверять только ключевые (зеленые) этапы.
- Минимум настроек и обслуживания: В атомарных тестах используется минимальное количество «созданий и разрушений», в частности, за счет сокращения взаимодействий с пользовательским интерфейсом. Например, мы можем сократить взаимодействие с пользовательским интерфейсом в AddItemToCart до ключевых шагов (выделены желтым цветом), абстрагировав компоненты создания и удаления с помощью методов и операций, которые не зависят от UI (выделены серым цветом). Цель состоит в том, чтобы ограничить UI-тест тем, что необходимо, и ничего больше, и это повысит надежность.
Атомарный тест ограничен.
- Независимость: Атомарные тесты выполняются независимо друг от друга. Эта независимость гарантирует, что результат одного теста не повлияет на результаты другого. Например, если мы разделим наш сквозной тест AddItemToCart на два, у нас будет два независимых теста, на которые не влияют другие тесты. Это поможет эффективнее определять источник ошибки, а значит улучшает точность.
Атомарный тест: Независимые тесты помогают изолировать ошибки.
Мы можем добиться большей атомарности, абстрагируя компоненты создания и удаления (setup and teardown) с помощью методов, не зависящих от UI. Уменьшая площадь поверхности UI-автоматизации, можно добиться ускорения выполнения, повышения надежности и точности. Эти преимущества закладывают основу для расширения тестового покрытия более масштабируемым способом.
Теперь, когда мы понимаем механизмы и преимущества атомарного тестирования, давайте быстро разберемся, насколько атомарным должен быть тест, чтобы считаться атомарным.
Какой тест считать атомарным
Традиционные стратегии сквозного тестирования предполагают полное покрытие большими «многоступенчатыми» тестами. Атомарное тестирование нарушает эту норму, разделяя сложные наборы функций на мелкие блоки. Каждый блок делится на отдельные самостоятельные тесты.
Процесс разбиения больших тестов на сфокусированные блоки дает еще одно преимущество: он заставляет вдумчиво рассматривать каждый функциональный компонент приложения, прежде чем изолировать его. Эта задача требует соблюдения тонкого баланса — достижения минимально необходимого объема теста, и при этом надо позаботиться, чтобы не был упущен ни один критический аспект, например тестирование ключевых зависимостей. Это соответствует моему предыдущему описанию атомарности как наименьшей единицы теста, предназначенной для верификации части функциональности.
Определение того, что представляет собой «наименьшая единица», может быть разным. Кто-то считает, что в идеале атомарный тест должен содержать всего два или, в крайнем случае, три assertions. Упрощение тестов до такой степени может показаться неправильным, но даже небольшие шаги на пути к этой цели помогут улучшить процессы.
