Что проверял в JSON

Что я проверяю в JSON

При тестировании JSON (JavaScript Object Notation) — универсального формата для обмена данными между клиентом и сервером — я фокусируюсь на нескольких критических аспектах, от которых зависит стабильность и безопасность приложения. Мой подход комплексный и включает валидацию как структуры, так и содержимого.

1. Валидация структуры и синтаксиса

Прежде всего, я проверяю, что JSON является корректным с точки зрения синтаксиса: соответствует стандарту RFC 8259, все скобки и кавычки закрыты, разделители (запятые, двоеточия) расставлены верно. Для этого часто использую автоматические валидаторы.

// Пример НЕВЕРНОГО JSON (лишняя запятая в конце объекта)
{
    "id": 123,
    "name": "Test",
}

// Пример ВЕРНОГО JSON
{
    "id": 123,
    "name": "Test"
}

Ключевые проверки структуры:

• Соответствие схеме (Schema Validation): Использую JSON Schema для строгой проверки структуры. Это гарантирует наличие обязательных полей, правильные типы данных, допустимые диапазоны значений и форматы (например, date-time для строк с датой).
• Наличие/отсутствие полей: Проверяю, что ответ содержит все обязательные поля, объявленные в API-контракте (Swagger/OpenAPI), и что нет лишних, недокументированных полей, что может быть признаком утечки данных.
• Вложенность и сложность: Убеждаюсь, что глубина вложенных объектов/массивов соответствует ожиданиям и не приводит к ошибкам парсинга на стороне клиента.

2. Проверка типов данных и значений

Это основа содержательной проверки. Недостаточно, чтобы поле "age" просто существовало — нужно проверить его тип и допустимость значения.

• Корректность типов: string, number, boolean, null, object, array. Например, поле "isActive" должно быть булевым, а не строкой "true".
• Граничные значения и валидация: Проверяю минимальные/максимальные значения для чисел, длину строк, пустые строки "", нулевые и отрицательные значения там, где они недопустимы.
• Специфические форматы: Валидирую строки, которые должны соответствовать паттернам: email, URL, UUID, дата и время в формате ISO 8601, hex-цвет и т.д.

// Пример проверки с использованием JS (для наглядности логики теста)
const response = {
    "email": "user@example.com",
    "score": 105,
    "tags": ["qa", "json"]
};

// Проверка типа и формата email
if (typeof response.email !== 'string' || !response.email.includes('@')) {
    throw new Error('Неверный формат email');
}
// Проверка граничного значения
if (response.score < 0 || response.score > 100) {
    throw new Error('Score вне допустимого диапазона (0-100)');
}
// Проверка типа массива
if (!Array.isArray(response.tags)) {
    throw new Error('Tags должен быть массивом');
}

3. Семантическая целостность данных (Бизнес-логика)

Самый важный этап — проверка, что данные имеют смысл в контексте бизнес-логики приложения.

• Консистентность связей: Если в ответе есть "userId": 5, то в другом месте ответа или в связанном запросе должен существовать пользователь с таким ID. Сумма значений в массиве заказов должна совпадать с полем "totalSum".
• Целостность вычисляемых полей: Проверяю, что поля, которые, по логике, должны вычисляться на сервере (например, "discountedPrice": price * (1 - discount)), содержат правильные значения.
• Соответствие состоянию системы: После выполнения действия через API (например, создания заказа) ответ должен отражать новое состояние системы (статус заказа "created").

4. Обработка нестандартных и ошибочных ситуаций

Надежный API должен корректно обрабатывать edge cases.

• Пустые и null-значения: Как система реагирует на "data": null, "items": [] или полное отсутствие ключа?
• Экранирование и специальные символы: Проверяю корректность обработки Unicode, эмодзи, HTML-сущностей (<, >, &), кавычек и слэшей в строковых значениях.
• Большие объемы данных: Как ведет себя JSON при передаче очень больших массивов или глубоко вложенных структур? Не происходит ли обрезания, таймаутов или превышения лимитов памяти?

5. Безопасность

• Отсутствие чувствительных данных: Убеждаюсь, что в ответах случайно не «сливаются» пароли, токены, внутренние ID или техническая информация (стектрейсы ошибок в чистом виде).
• Защита от инъекций: Проверяю, что данные, которые могут быть интерпретированы (например, переданные в JSONP или встроенные в JavaScript), должным образом санитизированы.

Инструменты и подход

Для эффективной работы я использую:

• Postman / Newman или Insomnia для ручного и автоматизированного тестирования API с написанием сложных assertions на JavaScript.
• Joi или Ajv (для Node.js-окружения) для валидации по JSON Schema непосредственно в автотестах.
• Специализированные библиотеки в языках программирования (например, pydantic для Python, System.Text.Json для .NET) для десериализации и строгой проверки моделей данных.
• Статические анализаторы в CI/CD пайплайне для автоматической проверки синтаксиса и схемы.

Таким образом, проверка JSON — это не просто «получили ответ 200 OK». Это многоуровневый процесс верификации, нацеленный на гарантию того, что данные не только формально правильны, но и семантически точны, консистентны и безопасны для потребителя (клиентского приложения или другого сервиса).