Очень редко люди задумываются о том, чем отличаются качественные тесты от посредственных. Если тест отличный, то его попросту незаметно - он растворяется в процессе и про него вспоминают только в том случае, когда он ловит баг.
Мы работали над несколькими миллионами автоматизированных тестов (работа такая) и пришли к выводам, что есть 7 характеристик отлично написанных тестов:
Тест полностью автоматизирован (очевидно)
Тест повторяем: тест не ломается, если приложение не поменялось
Тест заканчивается валидацией
Тест достаточно стабилен, чтобы его использовать в CI/CD
Тест очень легко читать
Тест требует минимальной поддержки
Тест работает параллельно с другими тестами и не ломается
Давайте поясню, что имеется в виду.
Тест полностью автоматизирован
Иногда попадаются такие тесты, которые автоматизированы не полностью. Самые распространенные причины: либо это очень сложно (как в случае с медленными джобами), либо просто невозможно (как проверить, что касса таки открылась?). Мы не рассматриваем такие неполные тесты в этой статье.
Тест повторяем: тест не ломается, если приложение не поменялось
Это относится к основам генерации уникальных данных. Например, мы тестируем регистрацию. Очевидно, что если не генерировать уникальный емейл, то на продакшене такой тест, скорее всего, не будет работать.
Тест заканчивается валидацией
За исключением случаев, где нужно выполнить действия по зачистке данных и подобных действий, завершение валидацией является лучшей практикой. Это помогает убедиться, что последнее действие прошло успешно.
Тест достаточно стабилен, чтобы его использовать в CI/CD
Если тест регулярно ломается, то он недостаточно стабилен, чтобы использовать его в CI/CD. Так как практически любая компания пытается добиться CI или даже CD, то часто такой тест не просто бесполезен, но даже вреден, так как отнимает большое количество времени и все равно не может использоваться в CI автоматически.
Тест очень легко читать
Мы обычно не пишем тесты в одиночку. Часто это команда людей и нашим коллегам тоже приходится поддерживать наши тесты. Крайне важно, чтобы любой член команды мог разобраться в структуре теста, не тратя на это излишнее количество времени. Даже если мы пишем тесты в одиночку, иногда бывает очень тяжело понять, что тест делает и как, если он не написан специально для облегчения понимания.
Тест требует минимальной поддержки
Пункт очевидный, но не всегда соблюдаемый. Чем меньше мы тратим времени на поддержку, тем больше у нас времени на то, чтобы сделать что-то полезное, как, например, написать больше тестов.
Тест работает параллельно с другими тестами и не ломается
В какой-то момент, особенно для end-to-end тестов, мы сталкиваемся с тем, что прогон тестов занимает слишком много времени, это снижает скорость разработки и приводит к таким эффектам, как неоттестированный патч. На этом этапе мы обычно задумываемся о параллелизации, чтобы ускорить исполнение тестов. Если тесты были написаны так, что они могут быть запущены параллельно в любой последовательности и не пересекаться друг с другом, то это делает задачу параллельного исполнения просто задачей настройки инфраструктуры, а не задачей переписывания тестов.
Оригинально тут.
