Если пишешь бэкэнд на Laravel, API какой-нибудь, то лучше конечно сопровождать все это дело тестами. Даже если ты не адепт TDD, написать в тесте
$response = $this->json('POST', '/api/my-resource', [
'data' => $myData,
]);
и проверять $response — гораздо удобнее, чем вручную составлять запросы после каждого изменения.
Однако при написании таких тестов нужно помнить вот о каком нюансе. Обычно при тестировании запросов дополнительные сервисы имитируют. Например, если в реальном запросе у нас идет обращение к файлам на диске Storage::disk('files'), то в тесте мы используем mocking вот так: Storage::fake('files'), я об этом когда-то написал несколько букв. Соответственно, диск в тесте создается фейковый и тест не гарантирует, что в боевой ситуации реальный диск создастся и проинициализируется правильно. Что в общем-то касается и других фейковых объектов. А также подстановки csrf-токенов: при обращениях через $this->json() (или post(), или get() etc) csrf-токен подставится автоматически. Но это не гарантирует, что на продакшне клиент возьмет откуда-то этот токен и правильно его подставит.
Поэтому помимо обычных тестов может быть не лишним прикрутить тесты запросов «извне», например через cURL:
<?php
namespace Tests\Feature;
use Tests\TestCase;
class CurlRequestTest extends TestCase {
/**
* @test
*/
public function user_can_curl_post_to_get_data() {
$myData = 'Тестовая строка';
$json = json_encode([
'data' => $myData,
]);
$ch = curl_init('http://localhost/api/my-resource');
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_POSTFIELDS, $json);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
'Content-Type: application/json',
'Content-Length: ' . strlen($json))
);
$result = curl_exec($ch);
$this->assertEquals(200, curl_getinfo($ch, CURLINFO_HTTP_CODE));
$data = json_decode($result, TRUE);
$this->assertEquals([
'data' => 'Тестовая строка',
], $data['data']);
curl_close($ch);
}
}
