День 1199. #Testing
Тестирование в Реальной Жизни. Начало
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

1. Тесты бизнес-логики
Эти тесты включают в себя всё, что подтверждает, что ваша бизнес-логика работает: модульные тесты, интеграционные тесты, сквозные тесты и т. д. Конкретная их реализация может варьироваться, но суть в том, что они должны проверять бизнес-цели кода, а не его техническую структуру. Здесь нас не заботят приватные методы, вызываются ли методы в правильном порядке, правильность параметров или что-либо ещё техническое. Просто нужно убедиться, что вывод соответствует вашим ожиданиям.

Избегайте любых непроизводственных компонентов (имитаций). Используйте реальные базы данных, реальные конечные точки и т. д. Имитируйте их, только если вам нужно сделать тесты более надёжными или быстрыми. Не имеет значения, что тесты проходят, если приложение не работает. Убедитесь, что вы проверяете все уровни вашего ПО, включая сетевые рукопожатия, авторизацию/аутентификацию, разрешения и т. д. В идеале используйте инфраструктуру как код для создания новой среды тестирования каждый раз.

2. Сравнительные тесты и тесты производительности
Призваны убедиться, что ваше приложение работает в реальных сценариях. Можно взять производственные журналы, извлечь запросы, а затем запустить их для нового и старого кода, чтобы сравнить, совпадают ли выходные данные. Таким образом, вы можете убедиться, что приложение действительно работает. Здесь нужно помнить о нескольких вещах.

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

Во-вторых, законы о защите персональных данных (GDPR, CCPA и т. п.). Возможно, вашей тестовой среде не разрешено обрабатывать производственные данные, поэтому необходимо анонимизировать их (как в журналах, так и при передаче между приложениями). Кроме того, необходимо правильно обрабатывать географическую безопасность - если вашим данным запрещено покидать пределы ЕС, вы не сможете проводить тесты в другой стране.

В-третьих, нагрузочные тесты. Как правило, не стоит брать логи нагрузочных тестов и запускать на них сравнительные тесты. Поэтому важно уметь отличить в производственной среде реальный запрос от поддельного тестового.

Когда у вас есть логи для сравнительных тестов, вы достигаете ещё двух вещей: корректности кэша и базы данных в тестовой среде. После исполнения сравнительных тестов ваш тестовый кэш готов обслуживать трафик на полной скорости. Это очень важно, поскольку кэш должен быть масштабирован, чтобы поддерживать стабильное соотношение попаданий, чего может быть трудно достичь с поддельными запросами. Кроме того, теперь тестовая база данных заполнена достаточным количеством данных и, что более важно, реальными записями из реальной жизни.

Имея эти две вещи, можно начать выполнять тесты производительности. Можно просто продолжить воспроизведение производственного трафика в тестовой среде, но на этот раз для измерения производительности. Необходимо реплицировать производственную инфраструктуру, поэтому, если у вас есть кэши на внешних хостах в производственном кластере, нужно организовать их таким же образом в тестовой среде. То же самое относится к базам данных, сетевым вызовам и т. д. Имейте в виду, что это может стать дорогостоящим: в вашей лаборатории тестирования необходимо иметь характеристики аналогичные производственной среде. Тут придётся найти баланс между бизнес-требованиями и количеством денег, которые можно потратить на содержание лаборатории тестирования и проведение тестов.

Окончание следует…

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/