fbakiyev Тестирование API
Выбрать границу и критерий правильности
Изучи контракт, предположения клиентов, изменённое поведение и доступное тестовое окружение. Определи ожидаемый ответ и сохраняемый эффект независимо от реализации. Нерешённый вопрос о смысле поведения требует решения по контракту, а не проверки, которая лишь повторяет текущий результат.
Случаи, различающие ошибки
- Проверяй смысл ответа и состояние, а не только коды статуса. Отклонённое изменение должно оставить защищаемое состояние неизменным, успешное — создать нужный эффект, а не только синтаксически правильный ответ.
- При изменении границ доступа проверяй полномочия на ресурс с разными субъектами и ресурсами. Действительные учётные данные одной учётной записи не разрешают доступ к данным другой. Тестовые данные и учётные данные должны оставаться в разрешённом тестовом окружении.
- Для идемпотентных изменений различай повтор одинаковых данных, одновременные дубликаты, тот же ключ с другими данными и повтор после потери подтверждения. Наблюдай и возвращаемый идентификатор, и число эффектов: два успешных ответа не доказывают однократность эффекта.
- При изменении контракта проверяй поведение старых клиентов для обязательных полей, значений по умолчанию, null, перечислений и ошибок. Одна проверка схемы не доказывает, что развёрнутый клиент допускает новое значение ответа.
- Для пагинации используй одинаковые значения сортировки и наборы данных на границах размера страниц; для асинхронных результатов проверяй документированное окно согласованности. Ожидания при одновременной вставке или удалении должны следовать выбранному контракту, а не придуманной гарантии снимка.
Используй только случаи, связанные с существенными рисками. Повторы тестового клиента должны быть видимы: автоматический повтор может скрыть неуспешную первую попытку или создать тот дублирующий эффект, который тест должен обнаружить.
Реализация и результат
Изолируй тестовое состояние и удаляй только записи, созданные тестом. При необходимости подменяй внешние границы, сохраняя сериализацию запросов, смысл ошибок и проверяемую границу состояния. Заглушка сервиса не доказывает интеграцию с реальным сервисом.
При eventual consistency ожидай наблюдаемого условия с ограничением времени. По имеющимся данным обозначай таймаут как ошибку или ограничение окружения, а не как успех после паузы.
Верни исполняемые проверки, покрываемые ими случаи контракта, команды и результаты, а также важные пробелы интеграционной проверки. Если запрошено только проектирование тестов, верни случаи и критерии правильности, не заявляя об исполнении. Совместимость общих и публичных API должна оставаться явной.