Узнайте, как объединить различные типы тестирования в разумную стратегию, соответствующую вашему проекту.
Добро пожаловать обратно! В последней статье было заложено много основ о том, как подходить к различным типам тестирования и что они содержат, а также были разъяснены определения типов тестирования. Помните это маленькое мемное изображение ? Вы могли бы задаться вопросом, как все эти типы тестирования, о которых вы узнали, могут работать вместе.
Далее вы узнаете именно это. В этой статье дается введение о том, как объединить эти типы тестирования в разумные стратегии и выбрать ту, которая соответствует вашему проекту.
Вы можете сравнить стратегии с рядом форм, чтобы лучше понять их значение. Вот список стратегий с соответствующими размерами и сферами разработки.
Давайте подробнее рассмотрим стратегии и узнаем значение их названий.
Определите цели тестирования: Чего вы хотите достичь с помощью этих тестов?
Прежде чем вы сможете начать строить хорошую стратегию, определите цель тестирования. Когда вы считаете, что ваше приложение достаточно протестировано?
Достижение высокого тестового покрытия часто рассматривается как конечная цель разработчиков, когда дело доходит до тестирования. Но всегда ли это лучший подход? Возможно, есть еще один критический фактор, который следует учитывать при выборе стратегии тестирования — удовлетворение потребностей ваших пользователей.
Как разработчик, вы также используете множество других приложений и устройств. В этом отношении вы являетесь пользователем, который полагается на все эти системы, чтобы «просто работать». В свою очередь, вы полагаетесь на бесчисленных разработчиков, которые делают все возможное, чтобы их приложения и устройства работали. Чтобы изменить это, как разработчик, вы также стремитесь оправдать это доверие. Поэтому вашей первой целью всегда должна быть поставка работающего программного обеспечения и обслуживание ваших пользователей. Это распространяется и на тесты, которые вы пишете, чтобы гарантировать качество приложений. Кент С. Доддс очень хорошо резюмирует это в своей статье Статическое против Модульного против Интеграционного против E2E Тестирования для Frontend приложений :
Чем больше ваши тесты соответствуют тому, как используется ваше программное обеспечение, тем большую уверенность они вам могут дать.
Кент С. Доддс
Кент описывает это как обретение уверенности в тестах. Чем ближе вы становитесь к пользователям, выбирая подходящий тип тестирования, тем больше вы можете доверять своим тестам в том, что они дадут достоверные результаты. Другими словами, чем выше вы поднимаетесь по пирамиде, тем больше вы становитесь увереннее. Но подождите, что такое пирамида?
Определение стратегий тестирования: как выбрать стратегию тестирования
В качестве первого шага определите, какие части требований вам необходимо проверить, чтобы убедиться, что они выполнены. Узнайте, какие типы тестов использовать и на каком уровне детализации вы можете достичь наибольшей уверенности, сохраняя при этом эффективную структуру затрат. Многие разработчики подходят к этой теме, используя аналогии. Вот наиболее распространенные из них, начиная с известной классики.
Классика: Тестовая пирамида
Как только вы начнете искать стратегии тестирования, вы, вероятно, столкнетесь с пирамидой автоматизации тестирования как с первой аналогией. Майк Кон представил эту концепцию в своей книге «Успех с Agile». Позже Мартин Фаулер расширил эту концепцию в своей статье «Практическая тестовая пирамида» . Вы можете изобразить пирамиду визуально следующим образом:
Как показано на этом рисунке, тестовая пирамида состоит из трех слоев:
Unit . Эти тесты находятся на базовом уровне пирамиды, поскольку они быстро выполняются и просты в обслуживании. Они изолированы и нацелены на самые мелкие тестовые единицы. Например, посмотрите на типичный модульный тест для очень маленького продукта.
Интеграция . Эти тесты находятся в середине пирамиды, поскольку имеют приемлемую скорость выполнения, но приближают вас к пользователю, чем модульные тесты. Примером интеграционного теста является тест API . К этому типу можно также отнести компонентные тесты .
Тесты E2E (также называемые тестами пользовательского интерфейса ). Эти тесты имитируют реального пользователя и его взаимодействие. Такие тесты требуют больше времени для выполнения и, следовательно, более дороги. Они находятся на вершине пирамиды.
Уверенность против ресурсов
Как кратко было рассмотрено ранее, порядок слоев не является совпадением. Они показывают приоритеты и соответствующие затраты. Это дает вам ясную картину того, сколько тестов вам следует написать для каждого слоя. Вы уже видели это в определении типов тестирования.
Поскольку тесты E2E находятся ближе всего к вашим пользователям, они дают вам наибольшую уверенность в том, что ваше приложение работает так, как задумано. Однако для них требуется полный стек приложений и имитируемый пользователь, поэтому они также потенциально являются самыми дорогими. Таким образом, уверенность напрямую конкурирует с ресурсами, необходимыми для выполнения тестов.
Пирамида пытается решить эту проблему, заставляя вас больше сосредоточиться на модульных тестах и строго расставлять приоритеты в случаях, охватываемых тестами E2E. Например, ваши самые важные пользовательские пути или места, наиболее уязвимые для дефектов. Как подчеркивает Мартин Фаулер, два самых важных пункта в пирамиде Кона следующие:
- Пишите тесты с разной степенью детализации.
- Чем выше ваш уровень, тем меньше тестов вам нужно будет пройти.
Пирамида эволюционировала! Адаптации тестовых пирамид
В течение нескольких лет дискуссии вращались вокруг пирамиды. Пирамида, похоже, слишком упрощает стратегии тестирования, упускает из виду множество типов тестирования и больше не подходит для всех реальных проектов. Поэтому она может вводить в заблуждение. Пирамида потеряла форму? У Гильермо Рауха есть мнение по этому поводу:
Пишите тесты. Не слишком много. В основном интеграция.
Гильермо Раух
Это одна из наиболее часто цитируемых цитат по этой теме, поэтому давайте разберем ее:
- «Пишите тесты». Не только потому, что это укрепляет доверие, но и потому, что это экономит время на обслуживание.
- «Не слишком много». 100% покрытие не всегда хорошо, потому что тогда ваше тестирование не будет приоритетным и потребуется много обслуживания.
- «В основном интеграция». Здесь снова акцент делается на интеграционных тестах: они имеют наибольшую ценность для бизнеса, предоставляя вам ежедневный высокий уровень уверенности при сохранении разумного времени выполнения.
Это заставляет вас снова задуматься о пирамиде тестирования и переключить внимание на интеграционное тестирование. За последние несколько лет было предложено много адаптаций, поэтому давайте рассмотрим наиболее распространенные из них.
Тестовый алмаз
Первая адаптация устраняет чрезмерный акцент на модульном тестировании, как показано в тестовой пирамиде. Представьте, что вы достигли 100% покрытия модульными тестами. Однако в следующий раз, когда вы будете проводить рефакторинг, вам придется обновить многие из этих модульных тестов, и у вас может возникнуть соблазн пропустить их. Поэтому они разрушаются.
В результате, а также в сочетании с повышенным вниманием к интеграционному тестированию может возникнуть следующая форма:
Пирамида превращается в ромб. Вы можете видеть предыдущие три слоя, но другого размера, а единичный слой был обрезан:
- Unit . Пишите модульные тесты так, как вы их определили ранее. Однако, поскольку они имеют тенденцию к размыванию, расставляйте приоритеты и покрывайте только самые критические случаи.
- Интеграция . Интеграционные тесты, как вы знаете, проверяют сочетание отдельных единиц.
- E2E . Этот слой обрабатывает тесты пользовательского интерфейса, аналогичные тестовой пирамиде. Будьте осторожны и пишите тесты E2E только для самых критических тестовых случаев.
Тестирование сот
Есть еще одна адаптация, представленная Spotify , которая похожа на тестовый ромб, но более специализирована для программных систем на основе микросервисов. Тестовые соты — это еще одна визуальная аналогия для детализации, области действия и количества тестов, которые нужно написать для программной системы на основе микросервисов . Из-за их небольшого размера самая значительная сложность в микросервисе заключается не в самом сервисе, а в том, как он взаимодействует с другими. Поэтому стратегия тестирования для микросервиса должна в первую очередь фокусироваться на интеграционных тестах.
Эта форма напоминает нам пчелиные соты, отсюда и название. Она имеет следующие слои:
- Интегрированные тесты . Статья Spotify использует цитату из JB Rainsberger для определения этого уровня: «Тест, который пройдет или не пройдет на основе правильности другой системы». Такие тесты имеют внешние зависимости, которые вам нужно учитывать, и, наоборот, ваша система может быть зависимостью, которая ломает другие системы. Подобно тестам E2E в других аналогиях, используйте эти тесты осторожно, только для самых важных случаев.
- Интеграционные тесты . Подобно другим адаптациям, вам следует сосредоточиться на этом слое. Он содержит тесты, которые проверяют правильность вашего сервиса более изолированным образом, но все еще в сочетании с другими сервисами. Это означает, что тесты будут включать и некоторые другие системы и фокусироваться на точках взаимодействия, например, через тесты API.
- Тесты деталей реализации . Эти тесты напоминают модульные тесты — тесты, которые фокусируются на частях кода, которые естественным образом изолированы и, таким образом, имеют собственную внутреннюю сложность.
Если вы хотите узнать больше об этой стратегии тестирования, ознакомьтесь с публикацией Мартина Фаулера, в которой сравнивается тестовая пирамида с сотами, а также с оригинальной статьей Spotify .
Испытательный трофей
Вы уже можете видеть повторяющийся акцент на интеграционных тестах. Однако другой тип, с которым вы столкнулись в предыдущей статье, не является тестированием в теории, но все еще является важным аспектом, который вы должны учитывать в стратегии тестирования. Статический анализ отсутствует в пирамиде тестирования и в большинстве адаптаций, которые вы видели до сих пор. Есть адаптация трофея тестирования, которая учитывает статический анализ, сохраняя при этом фокус на интеграционных тестах. Трофей тестирования возник из более ранней цитаты Гильермо Рауха и был разработан Кентом С. Доддсом:
Трофей за тестирование — это аналогия, изображающая гранулярность тестов немного иным способом. Он имеет четыре слоя:
- Статический анализ . Он играет важную роль в этой аналогии и позволяет вам выявлять опечатки, ошибки стиля и другие ошибки, просто выполняя описанные выше шаги отладки.
- Тесты модулей . Они гарантируют, что ваш самый маленький модуль будет надлежащим образом протестирован, но награда за тестирование не будет подчеркивать их в той же степени, как пирамида тестов.
- Интеграция . Это главный фокус, поскольку он наилучшим образом сочетает стоимость и более высокую надежность, как и в случае с другими адаптациями.
- Тесты пользовательского интерфейса . Включая E2E и визуальные тесты, они находятся на вершине трофея тестирования, аналогично своей роли в пирамиде тестирования.
Чтобы узнать больше о награде за тестирование, ознакомьтесь с записью в блоге Кента С. Доддса на эту тему.
Еще несколько подходов, ориентированных на пользовательский интерфейс
Это все хорошо, но как бы вы ни называли свою стратегию — «пирамидой», «сотами» или «ромбом», — чего-то все равно не хватает. Хотя автоматизация тестирования ценна, важно помнить, что ручное тестирование по-прежнему необходимо. Автоматизированное тестирование должно облегчить рутинные задачи и освободить инженеров по обеспечению качества, чтобы они могли сосредоточиться на важных областях. Вместо того чтобы заменять ручное тестирование, автоматизация должна его дополнять. Есть ли способ интегрировать ручное тестирование с автоматизацией для достижения оптимальных результатов?
Тестирование ледяного рожка и тестового краба
Действительно, есть две адаптации пирамиды тестирования, которые больше фокусируются на этих способах тестирования, ориентированных на UI. Оба имеют преимущество высокой достоверности, но, естественно, более затратны из-за более медленного выполнения теста.
Первый, тестовый ледяной конус, выглядит как перевернутая пирамида. Без этапа ручного тестирования он также известен как тестовая пицца.
Ice cone больше фокусируется на ручном или UI-тестировании и меньше всего на модульном тестировании. Он часто формируется в проектах, где разработчики начинали работу, имея лишь несколько мыслей о стратегии тестирования. Ice code считается анти-шаблоном, и это справедливо. Он затратен с точки зрения ресурсов и ручной работы.
Тестовый краб похож на тестовый ледяной рожок, но с большим акцентом на E2E и визуальном тестировании:
Эта стратегия тестирования включает в себя еще один аспект: она проверяет, что ваше приложение функционирует и выглядит хорошо. Тестирующий краб подчеркивает важность визуального тестирования , определенного в предыдущей статье . Интеграционное тестирование, разделенное на компонентное и API-тестирование, отходит еще дальше на задний план, а модульное тестирование играет здесь еще более второстепенную роль. Более подробную информацию об этой стратегии тестирования вы можете найти в этой статье о тестирующем крабе .
Хотя эти две стратегии тестирования более затратны, они имеют свое место: например, в небольших проектах, где требуется меньше тестов или требуется охватить меньшую сложность. В этом случае полномасштабная стратегия тестирования, сосредоточенная на интеграционном тестировании, может оказаться чрезмерно сложной.
Хотя эти две стратегии тестирования более затратны, они имеют свое место, например, в небольших проектах, которые требуют меньше тестов и не должны охватывать большую сложность. В этом случае полномасштабная стратегия тестирования, ориентированная на интеграционное тестирование, может быть излишне сложной.
Практический совет: давайте разработаем стратегию!
Теперь вы узнали о самых распространенных стратегиях тестирования. Вы начали с классики — тестовой пирамиды — и познакомились с ее многочисленными адаптациями. Теперь вам нужно оценить их для вашего продукта и решить, какая из них будет лучшей для вашего проекта. Ответ на этот вопрос должен начинаться с любимого всеми « Это зависит ». Но это не делает его менее точным.
Выбор наиболее подходящей стратегии тестирования из описанных — и даже из тех, что не были упомянуты — зависит от вашего приложения. Она должна соответствовать вашей архитектуре, вашим требованиям и, что не менее важно, вашим пользователям и их требованиям. Все это может отличаться от приложения к приложению. Это совершенно нормально. Помните, что ваша самая главная цель — обслуживать ваших пользователей, а не определять их по учебнику.
Чаще всего реальные тесты трудно разделить и определить по отдельности. Даже сам Мартин Фаулер подчеркивает положительный аспект различных определений , например, в случае модульных тестов. Как правильно отмечает Джастин Сирлс в своем твите :
[…] напишите выразительные тесты, которые устанавливают четкие границы, работают быстро и надежно и дают сбой только по полезным причинам.
Джастин Сирлс
Сосредоточьтесь на тестах, которые сообщают о реальных ошибках, с которыми могут столкнуться пользователи, и не отвлекайтесь от своей цели. Тесты должны быть разработаны так, чтобы приносить пользу пользователю, а не просто обеспечивать 100% покрытие или обсуждать, какой процент какого типа тестирования писать.
Сосредоточьтесь на тестах, которые сообщают об ошибках в реальной жизни, с которыми могут столкнуться ваши пользователи, и не отвлекайтесь от своей цели. Тесты должны быть разработаны так, чтобы приносить пользу пользователю, а не просто обеспечивать 100% покрытие или вызывать споры о том, какой процент определенного типа тестирования вам следует написать.