Эпизод 2: Василий в Мюнхене (май 2019 г.)
Предыдущие серии
Ненадежные тесты — распространенная проблема в Chrome. Они влияют на производительность других разработчиков и со временем отключаются. Отключение тестов означает уменьшение охвата тестами.
Этап сортировки
ВЛАДЕЛЬЦЫ каталогов несут ответственность за исправление ненадежных тестов. Если вы получили сообщение об ошибке в ненадежном тесте, потратьте несколько минут и прокомментируйте, что пошло не так в этой ошибке. Если у вас старый ненадежный тест и непонятно, что пошло не так, попробуйте просто повторно включить тест. Переназначьте ошибку как можно скорее, если это явно проблема в другом компоненте. Владельцы этого компонента должны лучше оценить неисправность.
Этап отладки
Ряд флагов командной строки полезен для исправления нестабильных тестов. Например, --enable-pixel-output-in-tests отобразит фактический пользовательский интерфейс браузера.
Имейте запасные инструменты , если отладчик устраняет нестабильность. Вполне возможно, что под отладчиком тест никогда не будет нестабильным. В этом случае могут пригодиться операторы журнала или base::debug::StackTrace .
Помните о распространенных причинах сбоев EXPECT__* , помимо ошибок в рабочем коде:
- Неправильные ожидания (например, безопасная страница означает HTTPS; вместо этого это может быть локальный хост).
- Условия гонки из-за того, что тесты не дождались подходящего события.
[Не тестируйте реализацию][не реализацию], а поведение.
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
В будущем два обхода могут превратиться в три, что сделает тест ненадежным. Однако имеет значение только состояние магазина. Вместо этого используйте наблюдателя для магазина.
Остерегайтесь распространенных шаблонов, таких как следующие:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
Подобный выше фрагмент теста браузера почти наверняка неверен. Существует множество событий, которые должны произойти в разных процессах и потоках, прежде чем появится какой-либо пользовательский интерфейс.
Ниже приведено правильное исправление:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
Исправление выше верно при условии, что WaitUntilCredentialPromptVisible() фактически не проверяет пользовательский интерфейс. Тесты браузера не должны зависеть от внешних событий пользовательского интерфейса, таких как «потеря фокуса» или «окно стало передним планом». Представьте себе реализацию, в которой приглашение появляется только тогда, когда окно браузера активно. Такая реализация была бы правильной; однако проверка фактического окна делает тест нестабильным.
Этап после исправления
Как только тест будет исправлен, запустите его локально сотни раз. Следите за Порталом нестабильности .