Daria Motorina

Мне кажется что тестовое сделано хорошо, но есть вещи которые немного некомфортны для потенциального проверяющего:
1) Хорошо бы было все команды по поднятию проекта завернуть в Makefile или bash сценарий
2) EmployeeScheduleController Аннотация Route на уровне класса это похоже на оверхед здесь, потому что только два эндпоинта и пустой роут над getWorkSchedule сразу пугает)) И private методы лучше сместить все вниз или вынести в базовый контроллер.
3) Employee создание класса Time тоже больше похоже на оверхед, с одной стороны хорошо, что все ограничения инкапсулированы в одном классе, с другой стороны операции с DateTime как-то более интуитивны.
4) EmployeeRepository Метод loadEmployeesFromFile() это точно не зона ответственности доктриновского репозитория, это отдельный класс, обычно сервис. Репозиторий это слой чтения из хранилища, а тут процесс записи.
5) DayFactory, TimeFactory, TimeRangeFactory и их интерфейсы кажутся очень большим оверхедом, потому что на небольшую логику созданы три класса и три интерфейса, про которые надо помнить и проверять их содержимое для поддержания общей линии приложения.
6) Обычно в симфони стараются придерживаться прямолинейной структуры папок, внутри Service есть Builder, ExternalApi, Factory и Validation - это разные группы задач и точно не сервисы, стоило бы оставить их в неймспейсе App (папке src) или выделить папку Module/Scheduler и создавать эти папки там.
7) Calendar - у этого класса зона ответственности это быть апи клиентом, можно его переименовать в CalendarApiClient, чтобы однозначно понимать что он дергает внешнее апи, а не просто сущность, как-то связанная с другим апи.
8) Validation - это необязательно, но обычно стараются по-максимуму использовать компонент Validator и логику дополнительных проверок строить вокруг него
9) ScheduleDirector может я раньше не встречалась с такой группой классов, но Director звучит контринтуитивно, Service или Manager немного привычнее и предсказуемее.
Тут есть противоречние - свойство scheduleBuilder не сеттится сразу, хотя оно необходимо для фунционирования, при этом его надо сеттить обязательно через сторонний метод. В симфони можно сконфигурировать класс заранее в services.yaml, задать ему алиас и уже готовый инжектить в нужный класс. Немного странно видеть исключения BadRequestHttpException, NotFoundHttpException в классе, зоной ответственности которого не является работа с http напрямую)
10) EmployeeNonWorkScheduleControllerTest - зачем использовать в качестве названий переменных подчеркивания? Может это ошибка? Просто выглядит очень странно)
11) В комментариях упоминали добавить коллекцию постмана, это было бы желательно

По идее указание скалярных типов на уровне php и маппинга доктрины должно хватать, можно указывать валидацию Type, чтобы именно средствами симфони ловить несоответствие или валидировать нескалярные типы.
Можно еще по этой статье делать (думаю что это самый правильный вариант)
How to validate raw values

Можно попробовать прикрутить rate limiter component, но имхо лучше создать свою логику набором правил, как оценивать частоту отправки формы и кастомное сообщение в случае превышения лимита

Раньше с таким не сталкивалась, но есть момент в описании вопроса - просто сделать эхо контента и exit не выйдет, чтобы вывести файл нужно еще добавить заголовки контента, размер файла и способ вывода. Т.е. в таком виде как метод контроллера есть сейчас я не понимаю, как он может корректно работать)
Даже если без доработок, то для предотвращения вывода контента файла в консоль достаточно использовать ob_start() и ob_get_clean().

Доработала пример:
Контроллер:

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\BinaryFileResponse;
use Symfony\Component\Routing\Annotation\Route;

class TestController extends AbstractController
{
    /**
     * @Route("/get-image", name="get_image")
     */
    public function getImage()
    {
        $path = "/home/dariia/Code/sf5_http_kernel_course/public/uploads/article_image/lightspeed-5f687f2402b6f.png";

        $response = new BinaryFileResponse($path);

        return $response;
    }
}

Тест:

<?php

namespace App\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class TestControllerTest extends WebTestCase
{
    public function testRegister()
    {
        $client = static::createClient();
        ob_start();
        $client->request('GET', '/get-image');
        $client->getResponse()->sendContent();
        $this->assertResponseIsSuccessful();
        $this->assertResponseHeaderSame('Content-Type', 'image/png');
        ob_get_clean();
...

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

Флоу
1.1. Создать listener/subscriber, словить сам событие (симфонивское или свое кастомное)
1.2. В хендлере события создать месседж с данными о нотификейшене (если нужно сохранять данные для другой обработки, то записывать в энтити, а в месседж дублировать), кидать месседж в шину
2. Создать хендлер месседжа
3. Настроить асинхронную обработку этих мессенджев в конфигах messenger
В документации есть очень похожий пример - creating-a-message-handler
В messenger есть отдельная конфигурация для retry.

Я не делала точно такую же систему, у меня были нотификейшены на другом фреймворке, а в курсе по symfonycasts о Messenger было много примеров по настройке этого дела) Думаю что стоит уточнить с заказчиком/менеджером точный флоу всех этих времен повторной отправки, хранения данных, подтверждения успешной отправки, потому что что-то может быть критически важно, а что-то второстепенно.

https://api-platform.com/docs/core/controllers/#cr...
Это похоже на то, что Вам нужно