-
Notifications
You must be signed in to change notification settings - Fork 52
CurlHttpClient: отправка файлов и массивы любой вложенности #112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
А тесты? ) |
Формирование url'а вынесено в отдельный класс и тесты на эту часть написаны. |
Сейчас для тестов https в Curl мы опрашиваем github. См HttpUtilsTest. ИМХО как минимум нужно убедиться, что POST запрос с файлами и прочим не приводит к 400 коду ответа. |
Не нравится мне идея что в unit тестах стучаться куда-то, особенно по многу раз... Как-то оно противоречит unit тестам. |
А если унаследоваться? Или выделить интерфейс, а реализации сделать разные? |
Пообсуждав тестирование пришли к следующем варианту, которое сделаю надосуге: <?php
print_r(array($_GET, $_POST, $_FILE, file_get_content('php://input')), true); В тесты будут выглядить так (кое-что сейчас в примере упускаю, типа HttpUrl, HttpMethod и т.д.): <?php
$post = array('a' => array('b' => array('c' => 'd')));
$request = HttpRequest::create()->setPost($post);
$response = CurlHttpClient::create()->send($request);
$this->assertEquals(print_r($post, true), $response->getBody()); |
Выглядит не плохо |
@crazedr0m наследование и вынесение не хочется делать, т.к. в случае CurlHttpClient все таки хочется протестировать именно правильную отправку curl запросов. Кирпичик которуй если замокать то теряется смысл его тестирования, зато при использовании в других классах надо его заменять на mock. А чем плох пункт 2? По мне так если в реквесте get параметры заданы, то должны участвовать в формировании url'а будь то post запрос или get. |
Добавил тесты, вскрылось два бага:
|
Мне нравится отправка файлов и кастомного тела пост запроса и не нравится преобразование многомерных массивов, я считаю что это не входит в обязанности клиента. |
Это уже входит в обязанности клиента, но ограничено лишь двумерными массивами. Он уже находится в состоянии "ни то ни сё". |
А что смущает то в преобразовании массивов? Вот есть у нас HttpRequest который мы заполнаем из $_GET, $_POST и т.д. Сам php входные параметры преобразует во многомерные массивы $_GET и $_POST. |
Контр аргументов более не получил, на днях замержу |
CurlHttpClient: allowing upload files and send post/get arrays with any deep lvl
На работе поковыряли немножко CurlHttpClient и захотелось еще дополнительно дома его доковырять, что бы он умел делать все что нужно:
В текущей версии вложенность для get и post ограничена двумерным массивом, однако более более глубокие массивы, возможно, кто-то получал заранее создавая массив вроде
array('a[b][c][0]' => '123')
. Теперь такие будет делать нельзя, т.к. теперь ключи массива прогоняются через urlencode так же как и значения.В случае HttpMethod::post предлагаю дополнять url параметрами из HttpRequest::getGet, так же как в случае HttpMethod::get
Сделана загрузку файлов, их нужно задавать так:
В случае если нужно только в одном конкретном случае оставить старую логику формирования post/get параметров добавлена настройка в CurlHttpClient: