- Стремитесь к максимальной линейности кода тестов.
Избегайте ветвления и циклов в тест-кейсах. Если хочется добавить в тесте if, значит, нужно разбить этот тест на два теста или подготовить тестовое окружение так, чтобы не было необходимости использовать ветвление.
- Избегайте зависимых тестов,
которые нужно запускать строго в определенном порядке. При росте количества автотестов вы захотите запускать их в несколько потоков параллельно, что будет невозможно при наличии зависимых тестов. А еще зависимые тесты очень не надежны. Подробнее: http://barancev.github.io/test-deps-are-evil/
- Постарайтесь, чтобы тест не полагался на контент, а готовил данные самостоятельно
и удалял после завершения. Используйте чистые браузеры и новых пользователей для лучшей воспроизводимости.
- Абсолютная линейность assert-проверок.
Когда вы пишете assert-утверждения в функциях, не следует использовать ветвления и циклы. Логика проверок должна быть линейна, иначе разбор багов и починка автотестов будут стоить очень дорого.
- Именуйте проверки в одинаковом стиле,
чтобы по первому взгляду можно было понять, что это именно проверка. Например, можно именовать функции по шаблону should_be_smth:
def should_be_reply_comment()
- Тесты именуются в одинаковом стиле.
Имена тестов должны хорошо отражать различия в похожих сценариях. Можно использовать те же подходы, что и при добавлении имен к тест-кейсам в тестовой документации. Например, test_guest_can_see_teach_button() — обратите внимание на явное указание на роль пользователя.
-
Одинаковые тесты, которые отличаются только каким-то контентом (например, языком интерфейса), следует не копировать, а параметризовать.
-
Пишите по возможности атомарные, неделимые тесты.
Писать один мега-тест, который проверяет вообще всё, не есть хорошая практика. Лучше написать десяток маленьких - проще будет локализовать проблему, когда она возникнет.