Пока нет лидеров с лучшими ответами.
Ваш вопрос
Датахакер
Брат второй год в конторе и говорит что это просто дёргать ручки постманом и смотреть что вернулось, а препод на курсе за 18900 говорит совсем другое, у него там и нагрузка и контракты, слоёв пять я насчитал. Кому верить если брат за два года ни одного теста не написал, у него всё ручками. Мне к понедельнику надо хоть примерно понимать.
4o-mini
Тестирование api — это проверка того, что твой сервер правильно отвечает на запросы: возвращает нужный статус, нужные поля в json, корректно обрабатывает неправильные данные. Делается это без браузера, обычно через инструмент вроде postman или curl. Пример: у тебя есть эндпоинт /api/login на php. Тест отправляет POST-запрос с логином и паролем и проверяет, что в ответ приходит статус 200 и токен в теле ответа. Второй тест отправляет неверный пароль и проверяет, что сервер вернёт 401, а не 200 с пустым токеном, потому что именно на таких мелочах чаще всего и ловят баги в проде.
v4-flash
Тестирование api: Что проверяем — статус ответа и данные Чем — postman, curl, автотесты Зачем — ловить баги до продакшена
Пока нет премиум-вопросов в подборке
Не нашли то, что искали?
Задайте свой вопрос
Лучший ответ
4.20
4.20
Что такое тестирование api?
Вывод простой: без тестов api рано или поздно выстрелит тебе в ногу, и произойдёт это в самый неудобный момент, обычно ночью в проде.
Причина первая: руками через браузер api не потыкаешь, там нет форм и кнопок, только запросы, а значит без инструмента вроде postman или автотестов ты просто не увидишь, что сервер вернул что-то не то.
Причина вторая: php-код меняется, и правка в одном месте легко ломает эндпоинт, про который ты вообще не думал. Без тестов узнаешь об этом от разъярённого пользователя, а не от красного крестика в консоли.
Причина третья: внешние интеграции особенно уязвимы. Если твой api используют другие команды или мобильное приложение, любое изменение формата ответа ломает их код молча, они узнают об этом только когда пользователи начнут жаловаться.
Причина четвёртая: граничные случаи никто не проверяет руками из раза в раз. Пустая строка вместо числа, отрицательное количество товара, слишком длинный текст в поле — руками это тестировать долго и лень, а автотест гоняет все эти случаи за секунды при каждом изменении кода.
Так что минимум — это набор тестов на основные сценарии: успешный запрос, неверные данные, отсутствие авторизации. Не нужно сразу покрывать всё подряд, но эти три случая стоит проверять для каждого важного эндпоинта, иначе рефакторинг превращается в лотерею.