Как тестируют в Google
Шрифт:
— Команда хочет еженедельно собирать статистику о покрытии кода и отслеживать его прогресс со временем.
Может быть и так, что все вышеперечисленные задания отправляются в систему выполнения тестов Google одновременно. Некоторые из тестов могут захватывать ресурсы, занимая общие машины на целые часы. Другим будет достаточно миллисекунд для выполнения, и они могут благополучно исполняться на одной машине с сотнями других тестов. Когда тесты помечены как малые, средние и большие, гораздо проще планировать расписание выполнения запусков, так как планировщик понимает, сколько времени может занять запуск, и оптимизирует очередь.
Система
Преимущества разных размеров тестов
Размер теста имеет значение. Он влияет на специфические преимущества теста. На рис. 2.5 показана общая сводка, а ниже мы приводим более подробный список достоинств и недостатков каждого типа тестов.
Рис. 2.5. Ограничения разных размеров тестов
Достоинства и недостатки больших тестов:
— Большие тесты проверяют самое важное — работу приложения. Они учитывают поведение внешних подсистем.
— Большие тесты могут быть недетерминированными (результат может быть получен разными путями), потому что зависят от внешних подсистем.
— Большой охват усложняет поиск причин при неудачном прохождении теста.
— Подготовка данных для тестовых сценариев может занимать много времени.
— Из-за высокоуровневости больших тестов в них трудно прорабатывать граничные значения. Для этого нужны малые тесты.
Достоинства и недостатки средних тестов:
— Требования к подставным объектам мягче, а временные ограничения свободнее, чем у малых тестов. Разработчики используют их как промежуточную ступень для перехода от больших тестов к малым.
— Средние тесты выполняются относительно быстро, поэтому разработчики могут запускать их часто.
— Средние тесты выполняются в стандартной среде разработки, поэтому их очень легко запускать.
— Средние тесты учитывают поведение внешних подсистем.
— Средние тесты могут быть недетерминированными, потому что зависят от внешних подсистем.
— Средние
Достоинства и недостатки малых тестов:
— Малые тесты помогают повысить чистоту кода, потому что работают узконаправленно с небольшими методами. Соблюдение требований подставных объектов приводит к хорошо структурированным интерфейсам между подсистемами.
— Из-за скорости выполнения малые тесты выявляют баги очень рано и дают немедленную обратную связь при внесении изменений в код.
— Малые тесты надежно выполняются во всех средах.
— Малые тесты обладают большей детализацией, а это упрощает тестирование граничных случаев и поиск состояний, приводящих к ошибкам, например null-указатели.
— Узкая направленность малых тестов сильно упрощает локализацию ошибок.
— Малые тесты не проверяют интеграцию между модулями — для этого используются другие тесты.
— Иногда сложно применить подставные объекты для подсистем.
— Подставные объекты и псевдосреды могут отличаться от реальности.
Малые тесты способствуют созданию качественного кода, хорошей проработке исключений и получению информации об ошибках. Более масштабные тесты ориентированы на общее качество продукта и проверку данных. Ни один тип тестов не покрывает все потребности продукта в тестировании. Поэтому в проектах Google мы стараемся использовать разумное сочетание всех типов тестов в каждом тестовом наборе. Автоматизация, основанная только на больших комплексных тестах, так же вредна, как и создание только малых юнит-тестов.
Малые тесты направлены на проверку качества кода, а средние и большие — на проверку качества всего продукта.
Покрытие кода — отличный инструмент, чтобы оценить, насколько разумно используется сочетание разных размеров тестов в проекте. Проект генерирует один отчет с данными покрытия только для малых тестов, а потом другой отчет с данными только для средних и больших тестов. Каждый отчет в отдельности должен показывать приемлемую величину покрытия для проекта. Если средние и большие тесты в отдельности обеспечивают только 20-процентное покрытие, а покрытие малыми тестами приближается к 100, то у проекта не будет доказательств работоспособности всей системы. А если поменять эти числа местами, скорее всего, расширение или сопровождение проекта потребует серьезных затрат на отладку. Чтобы генерировать и просматривать данные о покрытии кода на ходу, мы используем те же инструменты, которые собирают и выполняют тесты. Достаточно поставить дополнительный флаг в командной строке. Данные о покрытии кода хранятся в облаке, и любой инженер может просмотреть их через веб в любой момент.
Google разрабатывает самые разные проекты, их потребности в тестировании сильно отличаются. В начале работы мы обычно используем правило 70/20/10: 70% малых тестов, 20% — средних и 10% — больших. В пользовательских проектах со сложными интерфейсами или высокой степенью интеграции доля средних и крупных тестов должна быть выше. В инфраструктурных проектах или проектах, где много обработки данных (например, индексирование или обход веб-контента), малых тестов нужно намного больше, чем больших и средних.