Чекліст: що перевіряти в ендпоінті

Що перевіряти при тестуванні endpoint

Базово: статус-код, структура відповіді за схемою, типи й значення полів, заголовки (Content-Type, кешування, CORS) та час відповіді. Для POST, PUT і DELETE перевіряю побічний ефект: через GET або запит у БД. Також перевіряю відповідність документації Swagger.

Негативні кейси: відсутні обов'язкові поля, неправильні типи даних, порожні рядки й null, граничні значення довжини і чисел, зайві поля. Також неіснуючий ID (404), невалідний формат ID, неправильний метод (405), неправильний Content-Type (415). Помилки мають повертати зрозумілі повідомлення без стектрейсів і внутрішніх деталей.

Security та інше: запит без токена й з простроченим токеном, доступ до чужого ресурсу через зміну ID (IDOR), SQL-ін'єкції в параметрах. Далі — пагінація, сортування й фільтри, ідемпотентність, паралельні запити та rate limiting.

Позитивні й негативні кейси

Проходь цей список для кожного нового ендпоінта; на співбесіді його ж розказуй на питання «як би ти протестував цей API».

Позитивні

• Валідний запит дає правильний статус, схему і значення полів.
• Запис справді зберігся: перевірка через GET або SQL.
• Тільки обов'язкові поля і всі поля разом.
• Пагінація, фільтри, сортування; порожній результат = [], а не помилка.
• Час відповіді в межах SLA.

Негативні

• Без обов'язкового поля, з null, порожній рядок.
• Хибний тип: рядок замість числа, масив замість об'єкта.
• Граничні значення: 0, мінімум, максимум, максимум + 1, довгі рядки.
• Невалідний JSON і хибний Content-Type.
• Неіснуючий id дає 404; непідтримуваний метод — 405.
• Дублікат унікального значення дає 409.
• У всіх випадках — 4xx із зрозумілим повідомленням, без stack trace і без 500.

Негативних кейсів зазвичай більше, ніж позитивних, і саме вони знаходять більшість багів у валідації.

Безпека й фінтех

Безпека й доступ

• Без токена, з простроченим і зіпсованим токеном — 401.
• Роль без прав — 403.
• Чужий id в URL — жодних чужих даних (IDOR).
• У відповіді немає паролів, повних номерів карток, внутрішніх полів.
• SQL-ін'єкція і спецсимволи в рядкових полях не ламають запит.
• Rate limiting — 429 після ліміту.

Фінтех

• Суми — точні десяткові: 0.1 + 0.2, округлення, копійки.
• Від'ємна сума, нуль, сума більша за баланс чи ліміт.
• Повтор з тим самим Idempotency-Key — без подвійного списання.
• Валюта: коди ISO 4217, непідтримувана валюта.
• Баланс відправника й отримувача після переказу сходиться; при помилці нічого не списано частково.
• Дати й часові пояси: формат ISO 8601, операції біля півночі.

Пункт про 0.1 + 0.2 нагадує, що в JavaScript це дає 0.30000000000000004. Якщо бекенд чи фронтенд рахує гроші у float, копійки рано чи пізно «пливуть», тому суми мають зберігатися в десяткових типах або в мінімальних одиницях (копійках).