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