В Ларавеле довольно удобно сделана валидация данных во входящих запросах. С её помощью можно валидировать даже массивы, в том числе и вложенные. Документация на этот счет слегка лаконична, поэтому позволю себе небольшой пример.

Допустим, мы хотим принять массив с переменным количеством элементов, а в каждом элементе чтобы были поля id и weight. Вот так:

[
  'items' => [
    ['id' => 1, 'weight' => 5],
    ['id' => 5, 'weight' => 4],
    ['id' => 7, 'weight' => 3],
    ['id' => 8, 'weight' => 2],
    ['id' => 9, 'weight' => 1],
    // ...
  ],
]

Тогда нам нужно, чтобы поле items в запросе — присутствовало и было массивом, а значения id и weight — присутствовали и были целыми числами. Валидируется это так:

$data = $request->validate([
    'items' => 'array|required',
    'items.*.id' => 'integer|required',
    'items.*.weight' => 'integer|required',
]);

Таким образом будет отсечено все кроме поля items, в котором во всех элементах останутся только поля id и weight. Если по какому-то из значений вложенных элементов будут ошибки, то в errors они попадут с ключами items.i.id и items.i.weight, где i — индекс элемента в массиве items.

Если пишешь бэкэнд на 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);
    }

}

Допустим, у нас есть модель Post и у неё есть теги Tag, множественная связь. И мы загрузили несколько моделей постов с тегами, например вот так:

$posts = Post::with('tags')->all();

В $posts находится, конечно, коллекция. Теперь, если нам нужно собрать со всех постов теги в одну коллекцию, причем чтобы не было дублей, можно это сделать вот так:

$posts = Post::with('tags')->all();
$tags = $posts->reduce(function (Collection $collection, Post $post) {
    $collection = $collection->merge($post->tags);
}, collect());

Feel da power of Laravel collections!

В Laravel довольно удобно сделана валидация данных, переданных в запросе (например, от формы). Достаточно написать в контроллере

$data = $this->validate($request,[
    'myvalue' => 'required|integer',
    'myfile' => 'file',
    // ...
]);

и в $data попадет отвалидированный массив данных, если все условия соблюдены. А если нет — будет возвращен код ошибки 422 с соответствующими сообщениями.

Перечень доступных из коробки правил можно найти в документации. Иногда их оказывается недостаточно. У меня вот, например, возникла нужда отвалидировать, что пользователь загрузил файл docx. Стандартное правило должно по идее выглядеть вот так:

'myfile' => 'file|mimes:docx',

но на деле оказывается, что оно не работает.

В документации на фреймворк я не заметил об этом ни слова. Но оказывается, в Ларавеле обновление моделей по $model->update() действительно происходит только если переданы данные, отличающиеся от уже сохраненных. А если данные переданы те же, никакого апдейта не случится, и даже updated_at останется тем же.

Заметил случайно, когда чесал репу — почему же я запускаю скрипт апдейта данных из внешнего реестра, а время в updated_at по-прежнему равно времени создания. Хотя и тесты проходят, и скрипт запускается без ошибок. А вон оно как.

Если все же нужно, чтобы время обновления поменялось даже если запроса не было, надо использовать метод $model->touch().

Мне кажется, такие вещи в документах нужно писать большими буквами рядом со счетчиком уже пострадавших программистов.

First, I want to admit that there are a lot of ways to implement or even think about multi-tenancy. For more thoughts on this, I recommend a wonderful presentation called Multi-Tenant Laravel by Tom Schlick. In this article, I will show multi-tenancy based on single database and Laravel Global Scopes.

Now, let’s add multi-tenancy to our database entries. Let’s imagine we have DB table called posts, and we want each user to see only their own posts.

Use Laravel Observers and Global Scopes to Create User Multi-Tenancy

Через один observer куда элегантнее, чем пихать сохраненение user id (или другой сущности-владельца!) в каждый контроллер.

Вдогонку к предыдущему посту — пара слов про создание фейковых дисков для тестов.

Как гласит документация, с помощью фасада Storage мы можем легко создать фейковый диск для тестов. Достаточно выполнить код:

Storage::fake($disk_name);

где $disk_name — название диска (если не указать, будет создан фейк для дефолтного диска).

Дальше в доках говорится, что можно тестировать аплоады с помощью класса UploadedFile, и это всё достаточно просто и понятно. Но так как это практически всё, что написано в доках по данному вопросу — может сложиться ошибочное впечатление, что тестировать аплоады — предел наших возможностей с фейковыми дисками.

Что еще следовало бы, на мой взгляд, подчеркнуть, так это то, что фейковый диск — это не какая-то виртуальная конструкция с набором поддельных методов. Это самый настоящий диск, то есть директория, которая появится в storage/framework/testing. Так что с помощью фейкового диска можно осуществлять (то есть тестировать) ровно то же самое, что с помощью обычного. Создавать файлы и директории, обрабатывать файлы с помощью сторонних библиотек (PHPWord, к примеру), удалять, копировать и даже возвращать на скачивание.

Что довольно удобно, так как тесты не смешиваются с рабочими файловыми структурами проекта.

Допустим, у нас есть вот такой код (в контроллере, например для пути /documents/download):

return response()->download(
    $path, 
    'myfile.docx', 
    ['content-type' => 'application/msword']);

То есть выдача файла, находящегося в $path для скачивания под именем myfile.docx.

Протестировать, что файл отдается корректно, можно вот так:

use Tests\TestCase;

class DocServiceTest extends TestCase {

    /**
     * @test
     */
    public function user_can_download_document() {
        // обращаемся к пути, который отдает файл
        $result = $this->get('/documents/download');

        // проверяем http ok
        $result->assertStatus(200);

        // проверяем mime type
        $result->assertHeader('content-type', 'application/msword');

        // проверяем наличие аттача с заданным именем файла
        $result->assertHeader('content-disposition', 'attachment; filename="myfile.docx"');
    }
}

Сделать для того или иного материала теги — задача довольно типичная и распространенная. В этой заметке мы рассмотрим, как сделать модель тегируемой, а заодно — как реализовать автодополнение для этих тегов.

Для тегов в Laravel есть несколько пакетов (не с нуля же их писать), по описаниям мне подошел больше всего Spatie Laravel Tags. В нём работа с тегами реализована достаточно прозрачно и просто, плюс из коробки есть локализация для наименований тегов и slug-и для генерации страниц тегов.

Далее подробности.

Уже достаточно давно в свободное время штудирую курс Test Driven Laravel, посвященный, очевидно, применению методики TDD (Test-Driven Development) к разработке ПО на Ларавеле.

Курс последовательно, начиная с написания самого первого теста, демонстрирует разработку приложения по продаже билетов на концерты. Хотя я еще не изучил и половины, должен сказать, потраченных 150$ совсем не жалко (а сейчас он уже 250$, распродажи рулят). Вещает автор бодро и понятно. Все примеры и приложение в целом можно найти в закрытом репозитории на гитхабе. Причем, каждый коммит эквивалентен одному уроку, так что без труда можно повторить всю эволюцию рассматриваемого в курсе кода.

Вообще, видео-уроки я не очень-то люблю, но здесь формат совсем не раздражает (хотя текстовый вариант все равно был бы еще круче). Так что — рекомендую.

Что же касается самой методики TDD, мне кажется, у нас ей немного не повезло с локализацией названия. У нас это называется «Разработка через тестирование», то есть слово driven редуцировали до нашего «через».

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

При беглом ознакомлении с таким локализованным определением, понятно одно. Сначала надо написать тест, а потом код под этот тест. Ну ок, любопытная методика. А вот есть еще одна: можно сначала написать код, а потом не писать тест. Тоже прикольно, а главное — гораздо быстрее.

Между тем, оригинальное слово driven в названии явно обозначает подконтрольность одного явления другому. То есть, в данном случае — что ход разработки полностью подконтролен тестам, тесты ведут разработку, направляют её, что из переводной версии не очевидно.

И пока не попробуешь что-нибудь сделать «через тесты» сам, не очень-то ясно, что в самой методике главное отнюдь не наличие тестов на весь код в финале. Это лишь сопутствующая плюшка, хотя конечно тоже важная. Главное заключается как раз в слове driven. В том, что написанный тобой же тест при каждом запуске говорит тебе:

• Ты хотел по этому урлу увидеть данные, а урла такого чо-то нету. Может, добавишь?
• Вижу урл, только почему-то данных не вижу. Надо что-нибудь вывести.
• Урл пытается вывести объекты, но не знает, где их взять. Давай табличку в БД создадим?

И так далее. То есть суть в том, что если грамотно (в форме теста) описать желаемый результат, то не нужно даже особо думать, что еще ты забыл сделать и почему не работает. Лог очередного запуска теста сам тебе расскажет — чего не хватает. На мой взгляд, если эту суть осознать, методика предстает совсем в другом свете, нежели «давайте потратим в два раза больше времени, чтобы у нас был вагон тестов на каждый чих».

Как-то так.