Первый запрос осуществляет генерирование ссылки кода подтверждения, который нужен для смены пароля. Второй запрос дергает из базы сгенерированный код подтверждения, затем присваивает пользователю новый пароль. Так вот, после отработки данных запросов, от сервера возвращается 500-ая ошибка. А в логах пишется:
TESTSRV1 [ERROR] pid:2808 tid:89 2017-06-19 15:24:39.6715 UserAccounts.WebApi.Controllers.UserAccountsController testserv.ru/api/userAccounts/ChangePassword?Email=user149786@yopmail.com&ConfirmationCode=197538&NewPassword=321
Application_Error System.ArgumentNullException: Value cannot be null.
Parameter name: request
at UserAccounts.WebApi.Controllers.UserAccountsController.ChangePassword(GenerateNewPasswordRequest request) in C:\bamboo-home\xml-data\build-dir\DAHT-BE-BBAssemblyUserAccounts.WebApiControllersUserAccountsController.cs:line 189".
Также, пробовал добавить параметры в запрос по другому:
Изучите документацию к тестируемым endpoint’ам. Там должно быть описано - какие методы HTTP поддерживаются, какие заголовки ожидаются, формат запроса и так далее
Все. Разобрался. Надо было использовать метод bodyForm. Вдруг, если кому понадобится, то POST запрос составляется так:
Request.Post("http://testserv.ru/api/бла-бла-бла").bodyForm(new BasicNameValuePair("Парам1", Значение), new BasicNameValuePair("Парам2", Значение), new BasicNameValuePair("Парам3", Значение)).execute();
Я тебе про это и говорю. Тебе 500-ки приходят от бэка(не важно куда), а они ни в коем случае не должны приходить. У тебя не должно быть возможности получить 500-ку. Если получил - значит бэк не обработал какое то событие
Вот эта обвертка для запроса: "HttpResponse httpResponse1 = Request.Post(“http://тестовыйсервер.ru/api/…).execute().returnResponse();” специально предназначена для получения респонса от сервера. И при запуске кода в режиме отладки, как раз и видно, чего там сервер возвращает.
Для исследования 500-й ответа сервера недостаточно. В лучшем случае - там будет идентификатор ошибки, в худшем - ничего или бесполезная информация.
Вам нужно смотреть логи сервера в поисках реальной причины падения. Обычно девелоперы перед логированием такой “необычной” ситуации помещают какой-то уникальный идентификатор по которому потом можно будет найти это место в логах. Или же подойдите к девам и попросите чтоб они рассказали как именно искать “следы 500-ой”.
Если очень обобщить, то “на поверхности” сервера торчат его эндпоинты - точки входа в приложение. Внутри приложение состоит из нескольких слоев, и запрос, можно сказать, перемещается глубже и глубже. Само приложение выполняет какую-то функцию, однако перед тем как ее выполнять обычно сервер делает проверку вводных данных, состояния базы, еще чего-нибудь что требуется для того чтоб правильно обработать запрос. Например, проверяет что вводные данные находятся в нужном диапазоне. Если данные в порядке - то запрос обрабатывается. Если нет - то сервер должен в ответе дать понять клиенту что конкретно не так. В Вашем случае, возможно, имеет место такая ситуация: вы отправляете запрос с неверными данными (скажем, без обязательного поля “userName”), однако сервер неправильно их проверяет и считает валидными (скажем, программисты забыли сделать проверку на наличие поля). После этого сервер пропускает их глубже в себя, передает в какой-то сервис который ожидает валидных данных (скажем, not null userName), потому что внутри он собирается вызывать какой-то метод на этом поле. В итоге сервис падает с необработанной ошибкой (в данном случае - NPE), и клиенту возвращается 500-я.
Это только один из возможных раскладов, обработка запроса может упасть с необработанной ошибкой где угодно - от валидатора до формирования тела ответа. Так что, как я уже написал, нужно смотреть и анализировать логи. Вполне вероятно что за этой самой 500-ой кроется более общая проблема, а выявить ее с помощью лога будет значительно проще, чем тыкая пальцем в небо.
testomat.io управление авто тестами