Применение тестовой пирамиды к приложениям iOS
20 декабря 2022 г.Пирамида тестов, представленная Майком Коном в 2009 году, описывает стандарт, помогающий разработчикам планировать автоматизированные тесты программного обеспечения и расставлять приоритеты.
Это соответствует философии, согласно которой тесты, которые выполняются быстро и не требуют много ресурсов, должны включаться в набор тестов в больших количествах, тогда как дорогостоящие методы тестирования должны использоваться реже.
В этой статье подробно рассматривается пирамида и то, как ее можно применить для тестирования приложений iOS.
n Что такое тестовая пирамида?
Тестовая пирамида — это платформа, предназначенная для предоставления высококачественного программного обеспечения и надежного набора тестов.
В нем описываются различные типы тестов, которые должны выполняться группами разработки и обеспечения качества, а также определяется их порядок и частота. Цель использования этой платформы – максимально эффективное выполнение тестов и гарантия того, что изменения кода не повлияют на существующие функции.
Пирамида состоит из трех слоев, которые визуально представляют порядок различных типов тестов.
Модульные тесты, отображаемые на нижнем уровне, экономичны, требуют меньше времени для выполнения и поэтому должны составлять большую часть тестов.
Тесты пользовательского интерфейса, находящиеся в верхней части пирамиды, являются дорогостоящими, занимают больше всего времени и поэтому должны составлять меньшинство тестов.
Как выполняются тесты в приложениях для iOS?
При разработке для iOS обычно рекомендуется использовать платформу XCTest. Этот инструмент позволяет разработчикам автоматизировать тесты и интегрируется в рабочий процесс тестирования Xcode.
XCTest гарантирует, что условия, определенные разработчиком, выполняются во время выполнения кода, а также регистрирует сбои теста. Кроме того, XCTest может измерять производительность и взаимодействовать с пользовательским интерфейсом.
Давайте подробнее рассмотрим различные типы тестов в пирамиде и способы их выполнения с помощью XCTest.
Модульные тесты
Модульные тесты гарантируют, что изолированные блоки кода работают должным образом. Они не используют внешние зависимости и поэтому имеют ограниченную область действия. Когда модульные тесты выполняются для модуля, который вызывает внешнюю службу, эта служба имитируется.
Выполнение этих тестов на виртуальных устройствах, таких как эмуляторы, достаточно для экономии времени и ресурсов.
Модульные тесты должны учитывать каждый возможный сценарий, чтобы обеспечить высокий охват тестами. Например, если метод принимает необязательный параметр, то тесты должны быть написаны с этим вводом и без него. Чтобы добавить тестовый класс, разработчик создаст подкласс XCTest, содержащий модульные тесты для данного класса. Имя каждого метода тестирования должно начинаться с «тест».
Каждый метод тестирования состоит из трех частей:
- Упорядочить: создаются любые объекты, необходимые для проверки функциональности метода, такие как переменные класса и объекты, переданные в метод в качестве параметров. Зависимости от внешних служб заменены заглушками.
- Действие: метод или функция, которые необходимо протестировать, вызываются с использованием параметров, настроенных на этапе «Упорядочить».
- Утверждение. Тестовые утверждения, предоставляемые XCTest, используются для сравнения поведения кода на этапе «Действие» с ожидаемыми результатами, которые определяет разработчик. Если какое-либо утверждение ложно или во время выполнения возникает неперехваченное исключение, тест завершается неудачно.
Интеграционные тесты
В то время как модульные тесты проверяют правильную функциональность изолированных фрагментов кодовой базы, интеграционные тесты проверяют, как код взаимодействует с внешними компонентами, такими как сторонние службы и базы данных.
Интеграционные тесты гарантируют получение точных данных при обращении к внешним системам и эффективную работу приложения.
Поскольку им необходимо взаимодействовать с внешними интерфейсами, интеграционные тесты медленнее, чем модульные тесты, и для них требуется предварительная среда.
Некоторые виды интеграционного тестирования, такие как приемочное тестирование, можно проводить на виртуальных устройствах. С другой стороны, чтобы результаты были значимыми, тесты безопасности и производительности должны выполняться на реальных устройствах.
Еще один важный момент, о котором следует помнить, — использовать настройки устройства, соответствующие показателям целевого пользователя.
Разработка интеграционных тестов работает так же, как и модульных тестов, с той разницей, что хотя модульные тесты охватывают только изолированные части кода, интеграционный тест рассматривает поведение комбинации нескольких классов и функций. Поэтому используется меньше объектов-заглушек.
В конечном счете, интеграционные тесты направлены не на то, чтобы охватить все сценарии, а на то, чтобы подтвердить, что различные компоненты работают вместе так, как предполагалось. Например, интеграционный тест может проверить, сохраняется ли значение, полученное от контроллера, в модели, или что ошибка, возвращаемая внешней системой, передается пользовательскому интерфейсу.
Тесты пользовательского интерфейса
Тесты пользовательского интерфейса или сквозные тесты проверяют все приложение. Тестовые данные и тестовая среда используются для имитации реальной функциональности. Это самые дорогие и трудоемкие из трех типов тестов.
Тесты пользовательского интерфейса выполняются с точки зрения пользователя. Тестировщик рассматривает, как пользователь может взаимодействовать с приложением и какие ошибки он может совершить. Затем разрабатываются тесты, имитирующие эти действия.
Эти типы тестов могут быть хрупкими из-за непредсказуемых внешних зависимостей. Они также требуют использования физических, а не виртуальных устройств, чтобы точно имитировать проблемы пользователей. Точно так же важно проводить тестирование с различными настройками устройства и разной степенью сетевой задержки и регулирования.
Xcode предоставляет шаблон класса тестового примера пользовательского интерфейса с отправной точкой для тестов пользовательского интерфейса. Тесты пользовательского интерфейса также организованы как подклассы XCTest, но работают немного иначе, чем модульные и интеграционные тесты.
Чтобы создать тест пользовательского интерфейса, можно записать взаимодействие с приложением с помощью функции Xcode «Запись теста пользовательского интерфейса». Xcode запустит приложение и позволит разработчику взаимодействовать с пользовательским интерфейсом. Интерфейс приложения следует использовать так же, как и пользователь, чтобы определить, могут ли определенные задачи выполняться должным образом. Чтобы эффективно использовать более дорогие и трудоемкие тесты пользовательского интерфейса, они должны воспроизводить только самые важные пользовательские процессы с наибольшим влиянием.
При использовании функции «Запись теста пользовательского интерфейса» соответствующий код будет записан в метод тестирования, и разработчик должен добавить утверждения, необходимые для прохождения теста.
Каковы преимущества тестовой пирамиды?
Цель тестовой пирамиды – сэкономить время и ресурсы. Большое количество автоматических тестов снижает риск человеческой ошибки и позволяет команде разработчиков повторно использовать и масштабировать тесты приложений в соответствии с изменяющимися требованиями.
Тестовая пирамида также стала основным подходом в гибкой методологии, отдавая приоритет эффективности и результативности. Простейшие тесты выполняются первыми, чтобы выявить ошибки на ранней стадии, что позволяет тестировщикам более эффективно использовать свое время.
Группы обеспечения качества используют пирамиду в качестве эталона для правильной приоритизации различных типов тестов. Например, если количество тестов пользовательского интерфейса непропорционально велико, покрытие серверной части тестами будет ниже среднего. Ошибки могут быть обнаружены только после запуска тестов пользовательского интерфейса, тогда как они могли быть обнаружены намного раньше с помощью модульных тестов.
Во многих проектах тестовая пирамида используется без обязательного намерения команды. Когда разработка только начинается, писать тесты пользовательского интерфейса невозможно, а к моменту создания прототипа приложения у команды будет достаточно времени для написания модульных и интеграционных тестов.
Ограничения тестовой пирамиды для iOS-приложений
Принцип запуска большого количества низкоуровневых экономичных модульных и интеграционных тестов и меньшего количества трудоемких тестов пользовательского интерфейса можно применить ко многим программным приложениям и послужить прочной основой для разработки iOS.< /p>
Однако некоторые возражают, что невозможно обеспечить полнофункциональный пользовательский интерфейс без определенного ручного тестирования.
Как обсуждалось в этой статье, автоматизированные тесты пользовательского интерфейса должны охватывать только наиболее важные и важные рабочие процессы. Если бы был пограничный случай, когда, например, представление закрывало кнопку, делая кнопку недоступной для нажатия, эта ошибка, скорее всего, не была бы обнаружена только с помощью автоматического тестирования. Поэтому ручное тестирование на последних этапах перед выпуском всегда должно быть частью разработки iOS.
Кроме того, на тестовую пирамиду не следует смотреть слишком догматично. Каждый проект уникален, и есть сценарии, в которых тесты пользовательского интерфейса просты в обслуживании и могут часто выполняться. Как и в любой части процесса разработки программного обеспечения, крайне важно поддерживать гибкость адаптации набора тестов к изменяющимся требованиям.
Оригинал