Добавил тут себе в ботопотама для мониторинга сайтов вывод процентиля в графике значений пинга. Пользуясь случаем, рассказываю зафига они нужны, эти процентили, если вы вдруг не знаете.

Для начала немного определений и полезного матана.

Процентиль P — это такое число, что P% значений в наборе данных меньше или равны этому числу. Например, в наборе [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] число 8 — это 90й процентиль, т.к. 90% чисел в этом наборе меньше или равны 8. Из других примеров, 0й процентиль — может быть вам известен как минимум, 100й процентиль — максимум, а 50й процентиль вы можете знать под именем медиана.

Процентили — это, кстати, частный случай квантилей. Квантили — примерно то же самое, только выражены не в процентах, а в долях от 0 до 1 (ну или в вероятностях, если так удобнее). Процентиль — это квантиль*100%.

Численный показатель (не)годности статьи или заметки в блог можно было бы назвать (не)адеквантилем.

Итак, нафига нам эти процентили.

Сегодня поговорим о Test Driven Development, то есть о разработке, движимой тестами. О том, с чего вообще она начинается, как начать писать код, и как продолжить. Для примеров будем использовать Laravel, в этом фреймворке многое заточено под тесты, примеры наглядные и лаконичные. Поехали.

В литературе по тестированию и TDD в частности очень любят приводить в пример тест, что функция sum(a, b) успешно складывает два числа. Сложно представить что-то более вредное для демонстрации методики. Этот пример:

• скучный — поскольку по сути ничего не проверяет и ничего не демонстрирует;
• практически бесполезный — поскольку изначально не нуждается в тестировании*;
• не представляет собой важную функцию в нашем проекте*.

* если только мы не пишем реализацию математической библиотеки для какого-либо устройства, но там тесты будут совсем другие

Попробуем сделать пример получше. Итак, чтобы удачно стартануть в проекте с TDD, нужно совершить очень важный первый шаг. Выбрать первую фичу, которую мы хотим реализовать, и написать…

Недавно упоминал, что работаю над CRMкой для турагентств и турагентов, которую написал давно. Соответственно, Laravel уже очень старый. Я писал, что 6, а при проверке оказалось, что вообще 5, и это несколько сковывает мои возможности. В общем, решил осовременить систему, чтобы проще было работать и интегрировать более современные библиотеки (типа Horizon например). Поставил, короче, задачу обновиться за выходные. Ну и делюсь с вами полученным опытом.

А то в чатах иногда пишут, что практических примеров кодинга с ИИ маловато. Вот — самый настоящий практический пример.

Без лишних прелюдий, дано:

• Legacy-код на Laravel 5;
• набор из 580 тестов (код разрабатывался по TDD);
• Cursor AI бесплатная версия — чтобы было видно, что с ней, на автовыборе модели, тоже можно.

Нужно: обновить код до Laravel 12 так, чтобы он не сломался.

TL/DR если не хочется читать технические подробности:

1. ИИшечка помогает, но есть нюансы (внутри заметки).
2. Без ИИшечки я бы ещё очень долго это откладывал.
3. А без пакета заботливо написанных при разработке тестов скорее всего вообще не стал бы.
4. Задача была выполнена.
5. Суммарное время выполнения составило около 8-9 часов.

Итак, нам нужно обновить Laravel 5 до 12. Делаем мы это по шагам, то есть так: 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12, всего 7 обновлений. Для каждого разработчики Ларавела заботливо написали roadmap по апгрейду. Вот например для апгрейда до Laravel 6: https://laravel.com/docs/6.x/upgrade

Если поставить Laravel Starter Kit с Livewire внутри, который мы в прошлый раз немного поизучали, то у нас сразу, из коробки будет поддержка аутентификации. Но — только по электронной почте и паролю. А заказчики могут хотеть (и хотят) чтобы можно было входить с помощью логина, либо вместо почты, либо в качестве альтернативы. Причины могут быть разные, не будем зацикливаться. Вместо этого давайте посмотрим, как сделать, чтобы можно было использовать и логин, и почту в качестве идентификатора пользователя при входе.

Начнём как положено, с тестов. В tests/Feature/Auth у нас есть AuthenticationTest.php, в котором уже находятся дефолтные тесты аутентификации. Выберем главный опорный тест, на базе которого проведем изменения...

В Ларавеле есть удобный хелпер-метод: firstOrFail(), позволяющий получить по заданному запросу из БД первую найденную модель, либо вывалиться в 404, если моделей не найдено. Удобство в том, что использование хелпера позволяет избавиться от необходимости отдельно проверять наличие результата.

$page = ContentPage::where('slug', $slug)->firstOrFail();

вместо

$page = ContentPage::where('slug', $slug)->take(1)->get();

if ($page->isEmpty()) abort(404);

Очевидно, первый вариант лаконичнее и читабельнее.

Так вот, хотелось бы, чтобы то же самое можно было делать, когда мы хотим загрузить несколько моделей, или уйти в 404, если не нашли ни одной. То есть чтобы был хелпер-метод getOrFail(), который делает то же, что и firstOrFail, но возвращает несколько моделей.

Для этого можно написать макрос. В Laravel есть такой трейт, Macroable, и классы, которые его используют, можно расширять своими макро-методами. Расширим класс Illuminate\Database\Eloquent\Builder. Добавим в AppServiceProvider:

public function boot(): void
{
    // ...

    Builder::macro('getOrFail', function () {
        return tap(
            $this->get(), 
            fn ($results) => abort_unless($results->count(), 404)
        );
    });
}

теперь мы можем писать, например, так:

$contentPages = ContentPage::where('slug', $slug)->getOrFail();

и получим либо коллекцию моделей ContentPage, либо ошибку 404, без необходимости отдельно проверять, что коллекция не пустая.

P.S. Да, slug в данном примере не уникальный, может быть несколько моделей с одинаковым slug. Вместо этого у меня есть уникальный ключ ['slug', 'language'].

В 2017 году уговорил жену открыть турагентство, взяли домен, собрал сайт на OctoberCMS, и так появилось туристическое агентство AlayTravel. После чего, поскольку программировать я люблю, искать лёгких путей — нет, а жена вообще хотела всё записывать в эксель, сел писать для агентства систему CRM/документооборота. Взял Laravel и Vue.js, методику Test Driven Development, и через какое-то время написал. Жена начала пользоваться, а я — потихоньку дорабатывать первую «наивную» реализацию и думать, что с этим дальше делать. Ну, потому что писать целую CRM имея в виду работу одного агентства — это немножечко overkill чересчур.

Пока я думал и готовился, мир, аэропорты и туристический бизнес накрыло пандемией COVID-19. Все надели масочки, облились дезинфектором, и в аэропорты ездили, в основном, чтобы вернуть деньги за неиспользованные билеты. Стало сильно непонятно, что в такой ситуации произойдет с турбизнесом, но агентство мы не закрыли. И после пандемии туристы очухались, поправились, и снова стали летать.

И только я опять хотел вернуться к своей цеэрэмке, как началась СВО. И полетные программы несколько подсократились, и понимание чего там дальше будет немножко размыло. Но, видимо помня короновирус, туристы очухались и полетели. И в принципе стало ясно, что будут летать дальше (тьфу-тьфу-тьфу). К этому моменту у меня уже на CRM было не очень много времени, так что она работала себе и работала — для одного агентства.

Но несколько месяцев назад, когда на Ближнем Востоке активно летали ракеты, я подумал:

На днях начал работу над новым проектом, и выдался хороший случай попробовать Livewire и Volt с ним, с последней версией Laravel. Про Livewire в последних версиях Ларавела я раньше слышал и читал, но руки как-то не доходили. А теперь дошли и сейчас мы познакомимся с ним поближе.

Что такое Livewire

Что вообще такое Livewire? Это фреймворк, позволяющий разрабатывать динамичные интерфейсы прямо на PHP. Как гласит главная страница фреймворка:

Powerful, dynamic, front-end UIs without leaving PHP.

То есть «мощные, динамичные фронт-энд интерфейсы, не покидая PHP». Ничего не понятно, но очень интересно. Ну, я немного разобрался (прочитал документацию!) Этот фреймворк позволяет нам, путём вставки специальных директив типа wire:model.live="filter" прямо в blade-шаблон, в html какого-нибудь инпута, сделать этот инпут динамическим. Или, как раньше говорили, его аяксифицировать.

То есть заставить элемент отправлять запросы на сервер без перезагрузки страницы и обновлять соответствующий view по данным в ответе на запрос

И это — без необходимости писать JavaScript-код, вообще. И хотя мы в примере ниже немного JS-кода напишем, это, строго говоря, действительно необязательно.

Когда мы пишеем тесты на бэкенд-путь, который возвращает данные с отношениями, ($order, в нём $order→user, в нём $order→user→plan и т.д.) — следует избегать проверять отсутсвие тех или иных id через assertJsonMissing(['id' => $order2->id]) и ему подобные методы. Когда тестов окажется много, и мы их запустим разом, инкремент-айдишники в таблицах побегут и в какой-то момент внутри $order, который в json есть, внезапно окажется $user у которого id такой же как у $order2, и тест не пройдет.

Имеется в виду запуск всего пакета тестов, например, в Laravel с включенным трейтом RefreshDatabase: таблицы БД после каждого теста чистятся, но структура заново не пересоздается. Это и быстрее, и более похоже на «живую» среду.

И мы будем голову ломать, почему вдруг этот тест сломался на ровном месте и почему это проявляется, только если сразу все тесты запустить. И ладно мы, мы-то быстро найдем почему. А вот если мы работаем с ИИ, он половину рабочего кода искромсает своми правками, пока допрёт, что это было. Если допрёт вообще — мой вот не допёр.

В общем, проверять json ответа без декодирования в массивы/объекты не очень хорошо, т.к. может повлечь подобные ложные мэтчи.

Неправильно:

  $response->assertJsonMissing(['id' => $order2->id]);

Этот код будет искать по содержимому всего json и рано или поздно найдет вложенную зависимость со случайно совпавшим id.

Правильнее будет например:

  $data = $response->decodeResponseJson('data');
  $this->assertNotContains($order2->id, array_map(function ($order) {
    return $order['id'];
  }, $data););
  // так мы явно показываем, на каком уровне вложенности тестируем
  // также можно использовать замыкания внутри assertJson(), позволяющие ходить по уровням структуры документа

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

Для определенности уточню, что использую я плагин Codeium для Visual Studio Code под Linux, тариф бесплатный. Никаких дополнительных настроек не применял, на сайте указано что плагином используются Chat GPT, Claude, DeepSeek и Gemini. Проект, с которым я работаю, написан на Laravel, в нём есть такая функция — на определенный route можно отправить post-запрос с сообщением, и это сообщение будет отправлено телеграм-ботом в соотвествующий чат.

Эта функция уже написана, на неё есть тесты, и она работает. А в данном примере мы создадим feature-тест, проверяющий ограничение на количество сообщений в день в соответствии с тарифным планом пользователя. Такого функционала в проекте еще нет, я его хочу создать в соответствии с методикой TDD. То есть сначала написав тест, а затем последовательно запуская его и исправляя появившиеся ошибки.

Вот для написания данного feature-теста я и применю ИИ. Открываем подходящий для теста файл, жмём Ctrl+I. Чат жопотэ, поехали!

В Ларавеле можно из отношения «один ко многим» сделать отношение «один к одному». Например, у нас есть модель Monitor, у которой может быть много дочерних моделей MonitorCheck:

class Monitor extends Model
{
    /**
     * Monitor can have many checks
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function checks() {
        return $this->hasMany(MonitorCheck::class);
    }

}

тогда мы можем объявить отношение для получения последней модели MonitorCheck так:

    /**
     * Monitor has a last check
     * @return \Illuminate\Database\Eloquent\Relations\HasOne
     */
    public function lastCheck() {
        return $this->checks()->one()->latestOfMany();
    }

Однако если мы захотим объявить отношение для последней модели с условием, так сделать не получится. Допустим, мы хотим последнюю модель MonitorCheck с проваленным тестом.

public function lastFailedCheck() {
    return $this->checks()->where('passed', '=', FALSE)->one()->latestOfMany();
}

Такой вариант не сработает, будет возвращать null. Причем, если убрать latestOfMany(), то отношение будет работать и вернет MonitorCheck с проваленным тестом, только не последний. А с latestOfMany() не будет работать, запрос будет составляться неправильно (точнее, не так, как мы хотели бы).

А правильно объявлять данное отношение так:

public function lastFailedCheck() {
    return $this->hasOne(MonitorCheck::class)->OfMany(
        ['id' => 'max'], 
        function (Builder $query) {
            $query->>where('passed', '=', FALSE);
        }
    );
}

Вместо id в ['id' => 'max'] можно использовать и другие поля, например, created_at, главное условие аггрегации описать.