Комментарии 5
del
Приятная статья, но есть пара вопросов касаемо финального JSON'a пользователя:
Почему вы используете null вместо пустой строки?
Для номера дома тип number будет фатальной ошибкой
Думаю что это однозначно дает понять что там ничего нет. Пустая строка в некоторых случаях может по разному интерпретироваться.
Поясните если не сложно. Как я понимаю можно просто добавить еще поле и будет скажем 166А на выходе.
Не стану переписывать и копировать уже написанные тексты и доводы, просто почитайте “Null References: The billion dollar mistake” (“Нулевые ссылки: ошибка на миллиард долларов”) и связанные статьи. Если коротко - null это только для ошибок.
А потом понадобится добавить ещё квартиру, которая тоже будет подаваться как number (а если номера дома нет?) и потом из x полей, ака отдельные столбцы в базе данных, с разным типом данных мы будем собирать одну строку, когда могли просто в самом начале определить номер дома как строку и не думать об этом. Тип number полезен только когда требуются арифметические действия, для всего остального лучше использовать строку.
Доброго дня. Общим ответом на оба вопроса будет то, что целью статьи не стоит обучение составления JSON с правильным сочетнием контекста названий ключей и типом данных. Целью как раз явлется то, что можно использовать JSON вместо CSV. Что это может быть удобнее и как это сделать.
Если пройтись по вашим вопросам, то:
1. А почему нельзя использовать в данном случае null? Отчество нередко не является обязательным полем для заполнения. Да, можно отправить пустую строку. Но я не вижу тут критичной разницы. Все дело в реализации. Если почему-то на уровне БД полю отчества проставлено что оно не может быть null, то да отсылать пустую строку может стать необходимостью. Но кейс несколько странный был бы на мой взгляд. В остальных случаях не вижу большой разницы. Тем более, что по некоторым данным null дешевле в плане занимаемой памяти, чем пустая строка.
2. Тут соглашусь. Действительно, ставить такой тип даных для поля, в котором значения могут быть чисто числовыми (в символьном контексте), а может и действительно быть передано с обозначением литеры. Поэтому тип строчного значения тут подошел бы больше.
Но опять же напомню, что цель статьи в указании на механику работы с JSON для описания тестовых данных. А многое в составе тела запроса зависит от того, что указано в документации и реализации. И чаще мы будем вынуждены следовать ей и заполнять наши JSON тестовыми данными в контексте требований докментации. Если только вы не разработчик и не имеете полномочий менять состав перменных и их свойства в коде.)
JSON как альтернатива CSV в Postman, или как описать тестовые данные быстрее и лучше