у нас с єтим все в порядке. + я обрабатьіваю и тело ответа и для 400 и для 200 (условно, если код 400, то текст ошибки такой-то и отправляем запрос еще раз. если 200, то опять же валидируем респонс и переходим к следующему тесту). Тут все очень зависит от корректности реализации со стороньі девелоперов + правильная обработка результатов.

согласна, что полагаться ТОЛЬКО на статус-код не есть хорошо.

Тут не совсем соглашусь.

ну а что надежного в проверке одно статус кода?

одно дело проверка JSONа, сразу видно даже изменения

а статус коды всегда на усмотрение разраба пишутся

> просто разработчикам крайне часто лень париться с кодами
нужно правильно воспитьівать разработчиков 😂 и бить по рукам за кривую рализацию

Тут то согласен на 300%:) но иногда приходишь на уже рабочее) и паттерн свой они менять не будут)

Та)) у меня студент рассказьівал что у него на проекте весь CRUD реализован через метот GET и через урл указьівается операция над ресурсом (напр. GET /books/create с body в запросе или GET /books/3/delete). и на все запросьі возвращают 200ки)))

так что теория и жизнь могут бьіть очень далеки. и всегда нужно учитьівать факторьі єти. и писать тестьі с учетом конкретного проекта

Тут вопрос изначально вопрос был на ретрай по статус коду.
Вполне стандартная практика ретраить запрос с экспоненциальным ожидаением пока тебе не придёт нужный статус код -> ответ.

Например, в том же azure storage частенько нужно ретраить почти все операции с блобами, если работаешь с высоконагруженным сервисом: https://docs.microsoft.com/en-us/rest/api/storageservices/blob-service-error-codes

А когда тебе вернулся нужный статус код, значит можно и ответ парсить и дальше смотреть, что там пришло. Если не то, то снова ретраить.

Проверять только статус код - плохая практика. Ретраить пока не вернулся нужный статус код - стандартная практика.

у меня гет и пост сугубо:) других нет)

я логику описал выше. Можно долго рассуждать об идеальном сферическом респонсе в вакууме, но стоит защищаться от "интересностей" в реализации от разраба

привет. можно делать так чтобы в поле Token сохранился только для меня. когда другой человек использует и сохранить другой токен, в моем компе не поменялся ?

можно линк дать

извините если написал не понятно

Держать его в переменных, записывать только в current value

щя попробую

Привет всем! Как я могу проверить кусок жисонины?  Нашел конструкцию типа:
pm.test("Your test name", function () {
   var jsonData = pm.response.json();
   pm.expect(jsonData).to.eql({
       "key1": "value1",
       "key2": 100
   });
});

Проблема в том, что у меня одно из полей будет массивом. Можно с кем-то в личке посоветоваться?

Тебе весь массив надо сравнить с чем-то или только какой-то элемент?

вот кусок жисона:

я хочу полностью массив проверить и поле name

Сделал что-то вроде:
pm.test("coeffVehiclePower", function () {
   var jsonData = pm.response.json();
   pm.expect(jsonData.risk[0].calcValue[0]).to.eql({
       "periodOfValue": [
                 {
                   "serialNumber": "1",
                   "value": 12345
                 }
               ],
               "name": "Имя"
   });

вообще, хотел сделать проверку на name и value. что бы они друг от друга не отрывались.