Ответ
Ожидаемое поведение системы при негативном тестировании (ввод невалидных данных или создание нештатных условий) — это корректная и безопасная обработка ошибок, а не выполнение основной функции.
Критерии корректного поведения:
- Стабильность: Приложение не должно аварийно завершаться (crash), зависать или допускать утечки памяти.
- Защита данных: Некорректный ввод не должен приводить к повреждению, потере или несанкционированному доступу к данным.
- Понятная ошибка: Система должна возвращать информативное сообщение об ошибке (желательно на языке пользователя/клиента), а не сырой стектрейс или пустой ответ.
- Соответствие спецификации: Ответ должен соответствовать договоренностям (например, HTTP 400 для неверного запроса, валидационная ошибка в JSON-ответе API).
Пример (тест API):
# Негативный тест: попытка логина с пустым именем пользователя
response = api_client.post('/login', data={'username': '', 'password': '123'})
# Ожидаемое поведение:
assert response.status_code == 400 # или 422
assert "username" in response.json() # поле с ошибкой указано
assert "required" in response.json()["username"][0].lower() # понятное сообщениеНегативные тесты проверяют граничные значения, неожиданные типы данных, экстремальные объемы и попытки нарушить бизнес-логику.
Ответ 18+ 🔞
А, слушай, вот это реально важная тема, про которую многие забывают, как про залупу под кроватью! Все пишут тесты, где всё красиво: «ввёл правильный пароль — получил доступ, ура!». А что будет, если в поле логина отправить не строку, а, например, целый JSON-объект размером в гигабайт? Или вообще null? Система должна не сдохнуть, а аккуратно сказать: «Чувак, ты дебил?».
Вот смотри, в чём суть. Когда ты делаешь негативное тестирование (то есть специально пытаешься всё сломать), правильный ответ системы — это не выполнить то, что ты просишь. Правильный ответ — это грамотно и безопасно обосраться!
Как понять, что обосралась она правильно, а не как попало? Есть чёткие правила, блядь:
- Не упала, не зависла, не пошла памятью подтекать. Это основа основ, ёпта! Приложение не должно просто так взять и вылететь с ошибкой сегментации, оставив пользователя в ебенях. И не должно висеть, как будто его кто-то в анабиоз отправил. Стабильность — её ебёт мать!
- Данные целы. Это же пиздец как важно! Из-за того, что какой-то мудак отправил в поле возраста слово «хуй», у тебя в базе не должны удалиться все заказы за прошлый год. Или, что ещё хуже, открыться доступ к чужим аккаунтам. Защита данных — это святое, нахуй!
- Сказала по-человечески, что не так. Представь: ты пытаешься залогиниться, а тебе в ответ приходит пятиэтажный стектрейс на языке программирования, который ты в жизни не видел. Или просто пустая страница. Это пиздец как бесит! Система должна вернуть сообщение, которое можно понять: «Поле «логин» не может быть пустым, идиот». Желательно, на языке интерфейса, а не на языке внутреннего ебанного лога.
- Сделала всё по правилам. Если у вас API, то на кривой запрос должен быть кривой ответ, но по стандарту. Хочешь 400 статус — получи 400. Ошибка валидации должна быть в оговорённом формате JSON, а не в виде HTML-страницы с котиками.
Вот, смотри, как это выглядит в коде, тут всё просто:
# Это мы специально делаем хуйню: пытаемся залогиниться с пустым логином
response = api_client.post('/login', data={'username': '', 'password': '123'})
# А теперь проверяем, что система не спизданула, а сделала всё как надо:
assert response.status_code == 400 # Или 422 — главное, что ошибка клиента, а не сервера (500)
assert "username" in response.json() # В ответе явно указано, какое поле насрало
assert "required" in response.json()["username"][0].lower() # И написано внятно, ЧТО именно не такПонимаешь? Мы не проверяем, что логин прошёл. Мы проверяем, что отказ от логина прошёл корректно! Вот в этом весь цимес негативных тестов.
И проверять нужно не только пустые поля, а всё, на что хватит твоей больной фантазии: граничные значения (отправить минус сто в поле «количество»), не те типы данных (число вместо строки), ебанутые объёмы (запрос на десять терабайт), и, конечно, все возможные попытки обойти бизнес-логику. Система должна быть как бронежилет — пусть в неё стреляют со всей дури, а она стоит и говорит: «Ну и хули?».