Ответ
Рекомендуется начинать с позитивных (happy path) проверок.
Почему?
- Верификация основной функциональности: Сначала нужно убедиться, что система работает корректно при корректных данных и условиях. Это основа.
- Раннее обнаружение критических дефектов: Если основной сценарий не работает, дальнейшее тестирование теряет смысл.
- Повышение уверенности: Успешное прохождение позитивных тестов дает уверенность в базовой работоспособности фичи.
Затем выполняются негативные проверки:
- Обработка невалидных входных данных.
- Проверка граничных значений.
- Тестирование поведения системы при ошибках и исключительных ситуациях.
Пример для функции валидации пароля:
def validate_password(password):
return len(password) >= 8 and any(c.isdigit() for c in password)
# 1. Позитивный тест (основное требование)
assert validate_password("Secure123") == True
# 2. Негативные тесты (обработка ошибок)
assert validate_password("short") == False # Слишком короткий
assert validate_password("nolNumbers") == False # Без цифр
assert validate_password("") == False # Пустая строкаТакой порядок помогает строить тестовое покрытие логично и эффективно.
Ответ 18+ 🔞
Да ты послушай, что эти умники в учебниках пишут! Сидят, блядь, теоретики, и рассуждают, как тесты писать правильно. А я тебе сейчас на пальцах, как в жизни.
Смотри, представь, ты купил новую тачку. Что ты сделаешь первым делом? Правильно, сядешь и поедешь, блядь! По нормальной дороге. Проверишь, заводится ли, едет ли, тормозит ли. Это и есть твой счастливый путь (happy path, ёпта). Если она с завода не едет — всё, пиздец, дальше можно не проверять, вези обратно в салон, а не пытайся выяснить, работает ли магнитола при минус сорока.
Вот и в тестах так же. Начинать надо всегда с позитивных проверок. Почему, спросишь? Да потому что, блядь, логично!
Во-первых, ты должен убедиться, что основная фича вообще жива. Что она делает то, для чего её задумали. Если кнопка "Купить" не покупает даже при идеальных условиях — нахуй все остальные тесты про ошибки оплаты. Дефект кричащий, его видно сразу.
Во-вторых, это фундамент, ёбана. Построил дом — проверь, не падает ли он просто так, от ветра. Потом уже смотри, выдержит ли ураган. Раннее обнаружение пиздеца — наше всё.
В-третьих, когда позитивные тесты проходят, на душе спокойнее. Чувствуешь, что система хоть как-то, но работает. А уже потом начинается самое интересное — издевательство.
А вот потом уже, сука, начинается развлекуха — негативные проверки. Это где ты включаешь внутреннего гопника и начинаешь долбить систему по всем слабым местам.
- Суёшь ей вместо пароля цифры — обработка невалидных данных.
- Пароль из 7 символов? Из 8? Из 100? — Граничные значения, блядь, наше всё!
- Выдёргиваешь сетевой кабель в момент оплаты — поведение при еблях и исключениях.
Смотри на примере, чтобы вообще ни хуя не осталось непонятного. Допустим, есть у нас функция проверки пароля. Тупая, но показательная.
def validate_password(password):
return len(password) >= 8 and any(c.isdigit() for c in password)Ну и как её тестировать по-нормальному?
1. Позитивный тест (основной сценарий, "тачка едет")
assert validate_password("Secure123") == TrueВсё, блядь, ок. Пароль длинный и с цифрой. Функция должна вернуть True. Если не вернула — всё, пиздец, дальше не работаем, пошли багу создавать.
2. Негативные тесты (издеваемся, как можем)
assert validate_password("short") == False # Слишком короткий, долбоёб
assert validate_password("nolNumbers") == False # Без цифр, пиши пропало
assert validate_password("") == False # Вообще пусто, нихуя не ввёлВот такой порядок — он как чёткий план в голове. Сначала убедись, что система вообще работает, а потом уже выясняй, насколько она неубиваемая. А то бывает, начнёшь с ебли системы вводом иероглифов, а она и на нормальных-то данных грохнется. Зачем время терять, ёпта?