Как передаются массивы в JSON
Что проверяют
Знаете ли вы синтаксис настолько, чтобы по ответу API сразу заметить невалидный JSON, и понимаете ли, какие проверки массивов нужны в тестах. Уточнение обычно такое: какие кейсы вы напишете на поле-массив в ответе.
Как отвечать
Сначала коротко про формат (RFC 8259):
- синтаксис: массив это упорядоченный список в квадратных скобках, элементы через запятую. Висячая запятая после последнего элемента и комментарии запрещены;
- типы элементов: строки, числа,
true/false,null, объекты и вложенные массивы, причём в одном массиве их можно смешивать. Значенийundefined,NaNи типа «дата» в формате нет, даты передают строкой, обычно в ISO 8601; - корень: документ может целиком быть массивом, не обязательно объектом;
- порядок: он значим,
[1, 2]и[2, 1]это разные значения.
Потом перейдите к проверкам. Контракт описывают JSON Schema: "type": "array", items, minItems, uniqueItems. В Postman это pm.response.json() и утверждения через pm.expect, в автотестах на Java удобны REST Assured и JsonPath, в Python библиотека jsonschema.
Кейсы на поле-массив: пустой массив, один элемент, много элементов и граница пагинации, дубликаты, null внутри, элемент не того типа, порядок сортировки, если он обещан. Отдельно проверьте, что пустой результат приходит как [], а не null и не отсутствием поля: клиенты часто падают именно на этом.
Стоит упомянуть, что в GET-запросе массив передают не JSON, а параметрами строки запроса, и конвенции разные: ids=1&ids=2, ids[]=1 или ids=1,2. Какую понимает сервер, нужно выяснить и проверить.
Где спотыкаются
Считают [], null и отсутствующее поле одним и тем же. Для клиента это три разных сценария, и баг чаще всего прячется между ними.
Сравнивают массивы без учёта порядка или, наоборот, требуют порядок там, где API его не гарантирует. Тест выходит либо слепым, либо нестабильным.
Не проверяют большие числа. Идентификаторы больше 2^53 теряют точность в JavaScript-клиенте, поэтому их лучше отдавать строками, и это стоит закрыть отдельным кейсом.