Илья

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

не включать его для консоли вообще.
или настроить чтоб дебаг-сессия не стартовала автоматом.

Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?

Это нормально. Безликие массивы становятся осмысленными сущностями. Такой код становится проще понимать и поддерживать.

Используемый вами подход называется data transfer object (DTO). Широко распространенная практика. DTO отлично сочетается с иммутабельностью, которая присутствует в ваших классах.

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

В результате, на каком-то уровне приложения, происходит выборка, а дальше создаются все необходимые объекты, и внедряются друг в друга. (кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача ?)

Называется ORM. Находится в ответственности ORM слоя/фреймворка.

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

А Python разработчики имеют дело в основном только с бэкенд - и понятия про фронтенд у них будут на уровне dummy html, css, bootstrap.

Угу... При таком подходе - с чего вы взяли тогда что у фронта будут достаточные знания о работе бекенда? Раз по-вашему бекендер только в dummy html может, - а фронтендер сразу с ходу сможет оптимизированные запросы к БД к примеру писать? )))) Если ваш фронтендер настолько крут - то в принципе незнание языка не помеха, поскольку язык - только инструмент.

Не правильный json, множественные корневые элементы.

[
   {
      "login":"igor",
      "password":"qwerty"
   },
   {
      "login":"igor",
      "password":"qwerty"
   },
   {
      "login":"igor",
      "password":"qwerty"
   }
]

https://www.php.net/manual/ru/language.types.array.php

За свою жизнь мне довелось поработать в веб-разработке, автоматизации газопроводов, бухгалтерии, автоматизации бизнеса и даже дизайнером рекламы и журналистом. И останавливаться пробуя новое пока не собираюсь) При этом образование у меня - радиотехника.

Образование не ограничивает круг возможных профессий, а жизнь иногда складывается так, что приходится заниматься совершенно неожиданными вещами. Выбирайте ту специальность, которая ближе Вам в данный момент, интернет здесь вряд ли подскажет оптимальный выбор, тем более что у каждого здесь свой собственный путь и своя правда - кто-то оканчивает ВУЗ и всю жизнь работает по специальности, а кто-то ищет себя в самых неожиданных областях.

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

Запрос в транзакцию поместите.

Потому что $count это не ограничение на количество замен, а туда записывается сколько раз сработала замена.

Потому туда надо передавать переменную, а не цифру.

sandbox.onlinephpfunctions.com/code/87f0105ff5614c...

str_replace(
    array|string $search,
    array|string $replace,
    string|array $subject,
    int &$count = null
): string|array

https://www.php.net/manual/ru/function.str-replace.php

А почему catch (Exception $e) ловит все остальные исключения, вы не задумывались? Ведь он не знает все особенности всех своих производных классов.

Блок catch обрабатывает исключение подходящего типа в порядке объявления этих блоков. Объект класса FileNotFoundException является также и объектом класса FilesystemException (как и объектом класса Exception).

Хотите обрабатывать отдельно FileNotFoundException, вставьте соответствующий catch-блок до catch (FilesystemException $e).