Упрощенная пирамида тестирования: получение максимальной отдачи от тестов

Домашняя страница InfoQ Статьи Упрощенная пирамида тестирования: получение максимальной отдачи от тестов

Этот товар на японском языке

10 апреля 2023 г., чтение 10 минут

к

Тайсон Глэдли

рассмотрено

Мэтт Кэмпбелл

Разработчики используют множество различных ярлыков для описания своих автоматизированных тестов (модульные, интеграционные, приемочные, компонентные, сервисные, сквозные, пользовательский интерфейс, база данных, система, функционал или API). Каждая из этих меток имеет различное семантическое значение, описывая либо объем теста, типы действий, которые выполняет тест, предмет теста или участников, участвовавших в тестировании. Обычно мы не согласны с тем, что означает каждый из этих ярлыков, и дискуссии об их определении, как правило, бесполезны.

Вместо того, чтобы спорить о том, какие ярлыки использовать и как их определять, я считаю более полезным использовать одно из двух прилагательных для обозначения каждого теста: медленный или быстрый. Эти метки могут быть столь же полезны при выборе состава набора тестов, позволяя разработчикам объективно классифицировать тесты без непродуктивных аргументов.

Программируйте, развертывайте и масштабируйте Java по своему усмотрению. Microsoft Azure поддерживает вашу рабочую нагрузку, предлагая широкий выбор, независимо от того, работаете ли вы над приложением Java, сервером приложений или платформой. Узнать больше.

Выбор тестовых меток оказывает важное влияние на состав набора тестов. Разработчики используют их, чтобы знать, когда писать тест для определенного поведения, какой тип теста писать и оценивать баланс набора тестов в целом. Если мы ошибаемся, мы получаем набор тестов, который либо не обеспечивает точного покрытия, либо обеспечивает покрытие по неприемлемой цене.

Когда следует писать тест для определенного фрагмента производственного кода? Разработчики, которые, как и я, практикуют экстремальное программирование (XP) или разработку через тестирование (TDD), часто отвечают на этот вопрос «всегда». Однако не каждый фрагмент кода следует тестировать автоматически. Для каждого предлагаемого теста сначала сопоставьте затраты на его написание с преимуществами.

Я не выступаю против написания тестов. Действительно, для большинства тестов это быстрая проверка и ответ — да. Однако эта проверка полезна, особенно если тест медленно выполняется, медленно пишется или его сложно поддерживать. В таких случаях задайте себе несколько вопросов.

Является ли тест дорогостоящим из-за дизайнерского решения? Можно ли провести рефакторинг кода для лучшего тестирования? Ваши тесты — первые потребители вашего производственного кода. Упрощение тестирования кода часто облегчает его использование, улучшая качество вашей кодовой базы.

Является ли тест дорогостоящим из-за подхода к тестированию? Поможет ли другой подход к тестированию написать этот тест? Рассмотрите возможность использования тестовых двойников, таких как фейки или макеты, вместо соавторов. Если вашим тестам требуется сложная настройка, извлеките ее в тестовый сценарий, который можно повторно использовать между тестами.

Будьте осторожны и не злоупотребляйте двойными тестами, поскольку они не обеспечивают такой уверенности, как настоящие сотрудники. Иногда это падение уверенности стоит простоты настройки, уменьшения продолжительности тестирования или повышения надежности. Однако слишком большая зависимость от двойников тестов может привести к тому, что ваши тесты будут связаны с вашей реализацией, в результате чего набор тестов обеспечит низкую достоверность и затруднит рефакторинг.

Является ли тест дорогостоящим, потому что поведение по своей сути сложно протестировать? Если да, подумайте о важности тестируемой функции. Если это важная функция, связанная с обработкой платежей, то тестирование может стоить затрат. Если это странный крайний случай в вашей логике отображения, вам следует пересмотреть, писать тест или нет.

Является ли тест дорогостоящим, потому что он непредсказуемо проваливается? В этом случае вам следует удалить его, переписать, чтобы он был более надежным, или отделить его от остального набора тестов. Чтобы набор тестов обеспечивал полезную обратную связь, вы должны быть уверены, что неудачные тесты представляют собой нежелательное поведение. Если вы обнаружите, что тест необходим и его невозможно сделать предсказуемым, переместите его в другой набор тестов, который выполняется реже.