A
я не осознал в чем особенность и отличие
Size: a a a
2021 October 11
RK
Корректность пакета, заполнение ключевых полей при выгрузке. Например, выкатили релиз, а теперь поля не заполняются. Пакеты с принимающей стороны не сериализуются, валятся ошибки. Вопрос, как разрешить такую ситуацию?\
RK
Может я вообще не с той стороны захожу
DO
вы же не end-to-end тестировать хотите, верно? если речь только про соответствие формату, то я бы предложил юнит-тест, который дергает метод, который формирует payload и сравнивает его с эталоном (или валидирует по схеме, как вариант)
A
мы принимаем или отдаем?
RK
Отдаем
A
вот сразу видно, человек сечет +)
NG
формат JSON-пакетов прекрасно валидируется через пакеты XDTO
A
мы когда отдаем, у нас есть метод сериализации. Вот его выхлоп и надо сравнивать с ожиданием
NG
накидывайте честную xsd-схему, пакуете ее в пакет xdto, читаете пакет фабрикой xdto, а не обычным ПрочитатьJSON. если пакет невалиден, получите эксепшен
RK
Мы через схему XDTO и сериализуем. Сериализовал JSON через схему, часть полей не заполнилось. В какой момент эксепшн вылезает? Не понимаю этого.
NG
я думал вы про десериализацию. для сериализации вызовите метод Проверить() на объекте XDTO
g
а это не дорого поддерживать xdto? может все таки сравнивать эталон с тем что вылетает?
g
в предложении смущает разделение обязанностей. тестирует тестировщик, код пишет - разработчик, а xdto находится в конфе, т.е. тестировщику нужно в конфе поддерживать и актуализировать xdto
КЧ
Тестировщик каждый json тестирует на валидность в ручную? Нормальный такой апи
g
кажется не предлагал сверять что-то в ручную
КЧ
Так а причем тут тестировщик вообще если речь про валидацию данных?
g
изначальный вопрос был "Вопрос, как это организовать в рамках тестирования?" из чего сделан был мой вывод что данным вопросом занимается qa
NG
xdto - это про формат и валидацию. не понимаю, как формат сравнивать по эталону.
NG
xdto должен писать разработчик, а не тестировщик. все сообщения между системами должны гулять по специфицированным форматам