Наиболее распространенной практикой при проектировании системы автотестов является минимизация взаимного влияния тестов между собой.
Для unit-теста "быть автономным" - аксиома. Для комплексных автотестов этот подход не всегда полностью применим. Но в этой статье речь пойдет не об этом.
Я хочу рассказать о способе, который может помочь в принудительном выявлении скрытых до поры до времени проблем в тестах, связанных с их явными и неявными зависимостями друг от друга.
Итак, имеем некоторый набор 4-х фазных тестов, которые время от времени проваливаются из-за недостаточной их изоляции друг от друга.
Это "время от времени" непредсказуемо и всегда не к стати.
Что можно сделать, чтобы выявить скрытые зависимости , от которых хотелось бы избавиться, не затеивая глобальной ревизии и перепроектирования системы автотестов?
Если у вас, как и большинства, тесты запускаются всегда в одном и том же порядке, то можно применить "метод перемешивания" автотестов. Сделав их порядок запуска каждый раз разным.
Чтобы это реализовать, скорее всего, потребуется реализация "перемешивателя" (mixer) списка тестов.
Отмечу, что не всегда можно просто взять и перемешать тесты.
Вот три основных типовых случая:
1. Ваши тесты ДОЛЖНЫ быть автономными согласно принятым у вас принципам автоматизации
Тут вы законно можете ожидать одинаковых результатов в независимости от порядка запуска
2. Ваши тесты сгруппированы. Порядок групп не важен, но внутри групп порядок обязателен. Перемешивайте группы тестов, оставляя порядок внутри групп постоянным.
3.зависимость между тестами - изначальный архитектурный принцип вашей системы автотестов.
В этом случае метод перемешивания неприменим.
Отмечу также, что не стоит отказываться от классического периодического прогона тестов в одном и том же порядке. Достаточно лишь организовать дополнительный периодический прогон "перемешанных" тестов.
Еще важно понимать, что данный метод не выявит сразу ВСЕХ проблемных зависимостей. Но постепенно от запуска к запуску позволит минимизировать их количество.
Так картина будет даже нагляднее..
Бывают интересные ситуации, когда тесты оказываются зависимыми неявно. Самое просто, что приходит в голову - статическая инициализация какого-то значения в программе при первом вызове метода (создании класса). Баги или недочеты в cleanup стадии - например тест не убирает за собой временный файл - если такой тест последний, все ок, сделался не последним и может возникнуть падение другого теста.
ОтветитьУдалитьДа, Вы привели наглядный пример. Вот как раз для выявления таких неявных зависимостей и предлагается "мешать".
ОтветитьУдалить