По какому принципу вы определяете приоритетность написания тестовых сценариев?

Да ты посмотри на эту классификацию, блядь! Как будто кто-то умный всё по полочкам разложил, а на деле-то — пиздец какой бардак в головах начинается, когда к делу приступаешь. Слушай сюда, я тебе сейчас на пальцах, как для дебила, объясню, как на самом деле приоритеты в тестах расставлять, чтобы начальство не ебло мозг, а продукт не развалился нахуй.

Первым делом, ёпта, надо понять одну простую вещь: если это сломается — всем пиздец. Вот это и есть твой наивысший приоритет, или, как умничают, «смок-тесты». Это не про красоту, а про то, чтоб система хоть как-то запустилась и не выплюнула пользователю в лицо ошибку 500 на главной странице. Представь, зашёл админ — а ему хуй с горы. И всё, приехали. Поэтому:

# Пример: Проверка доступности главной страницы и входа в систему
def test_smoke_main_flow():
    assert home_page.is_loaded()
    login("admin", "default_pass")
    assert user_dashboard.is_visible()

Сделал это — уже можно выдохнуть. Система жива, блядь. Не корчится в агонии.

Дальше, чувак, идёт самое сладкое — «счастливый путь». Это когда всё по учебнику: пользователь не идиот, данные правильные, звёзды сошлись. Надо проверить, что основная фича, ради которой всё и затевалось, работает. Создание заказа, формирование главного отчёта — вот это всё. Если тут косяк — заказчик тебе ебало набьёт, а проект накроется медным тазом.

А вот теперь, внимание, ебаный рот! Самый интересный этап, где ловят 80% всех косяков — негативка и граничные значения. Это когда ты начинаешь думать, как самый ебучий пользователь-распиздяй, который будет вводить в поле пароля пробелы, буквы ё, а в поле суммы заказа — «хуй». И система не должна сдохнуть, а должна вежливо сказать: «Иди нахуй, дружок, так нельзя».

# Пример негативного теста для формы
def test_login_with_empty_password():
    error_msg = login("valid_user", "")
    assert error_msg == "Password cannot be empty"

Проверил это — уже молодец. Потому что юзеры — они такие, блядь, найдут способ всё сломать. Подозрение ебать чувствую, что они только этого и ждут.

Потом уже, когда базовое не падает, можно лезть в интеграцию. Это когда твой модуль «А» должен поговорить с модулем «Б», а они, сука, как два барана, друг друга не понимают. Тут уже начинается весёлая жопа: «А я думал, ты шлёшь мне число, а ты мне строку!». Проверяешь стыки — и часто охуеваешь от того, что там творится.

Ну и в самом конце, когда уже все силы на исходе, а терпения — ноль ебать, берёшься за редкие сценарии и регресс. Типа: «А что будет, если пользователь зайдёт с левосторонней раскладкой в полночь во время високосного года?». И регресс — это чтоб новая фича не отъебала старую, которая пять лет работала.

Критерии, блядь, простые до безобразия:

• Сломается — всем пиздец? (Критичность) — Делай в первую очередь.
• Этим все пользуются каждый день? (Частота) — Делай сразу после первого.
• Код там такой, что сам чёрт ногу сломит, и его каждый день правят? (Сложность) — Обложи тестами, как одеялом, а то просыпаться будет больно.
• От этого зависит, не сядешь ли ты в тюрьму или не оштрафуют ли компанию на овердохуища денег? (Безопасность/Стандарты) — Да это ж вообще приоритет номер ноль, ёпта!

Вот и вся философия. Не умничай, а делай то, от чего меньше всего волосы выпадут и нервов потратится. Чих-пых тебя в сраку, понял?