Laravel по-русски

Ты придумал плохой тест.

Это никак не протестируешь (если не мокать магические методы).

Можно сделать установку значений через setUtmSource() и setUtmTerm() методы и замокать контроллер TopPageController. Но и это проблемотично, насколько знаю, laravel не пользволяет из коробки мокать контроллеры. Придется с роутами играться.

В идеале - контроллер обращается как-то к IoC (будь это фасад, прямое обращение app или DI) и достает оттуда некий класс, сеттер меток.
В тесте ты мочишь этот класс (мочишь вызов методов setUtmSource и setUtmTerm, сравниваешь ожидаемые аргументы и реальные) и этот мок кладешь в IoC.

Кстати, ты юзаешь $response = $this->get('/?utm_source=google&utm_term=keyword1%20keyword2'); - это уже не unit тест.

P.S. Научится писать тестируемый код должен каждый разработчик.

Норм. Главное придерживаться одной стилистики кода.
Я, в своих приложениях, разделаю валидацию на "аттрибутную" и "логическую".
Аттрибутная - просто проверяю, что значения валидны и дальнейший код, который с ним работает, не будет падать.
Логическая - уже разлетается по системе. Например проверка свободного номера в отеле. С одной стороны можно просто в реквесте добавить валидацию на признак свободности, но, а если мы хотим вип персонам предоставлять любой номер и выгонять текущих поселенцев? Если расширять валидацию реквеста, то как-то слишком жирно и не гибко.
Так-же бывают случаи, что заранее в реквесте неизвестны какие-то параметры и их нельзя узнать, не прибегая к грязному коду (например супер сложный подсчет скидок машин лернинга, в реквесте дергать какое-то апи скидок для валидации - очень спорно). Поэтому выносить сложную валидацию из реквеста - нормально.

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

Сделай OrderService с методом ->store(...args), в котором и проверяй всю сложную логику. Результат функции либо true, либо Exception (с ошибками валидации или иными ошибками логики).
Не понравится - логику можно будет легко разнести, если точка создания заказа одна (->store()).

Если хочешь в офис - портфолио не требуется (надеюсь ты не собираешься в интернет-агенства/веб-студии).

Не знаю в какой стране ты живешь, но в РФ практически все хорошие специалисты в крупных компаниях либо в стартапах, т.е. не советую идти в офис пока уровень экспертизы не дорастет до мидла, чтобы была возможность попасть в хорошую команду. На фрилансе этого уровня можно добиться в разы быстрее (раз уже такая возможность есть).

Если уж очень хочется переехать и в офис - то лучше читай хорошие книги, на интервью своим портфолио не похвастаешься (если конечно ты не сделал что-то действительно крутое).

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

P.S. сужу по своему опыту

У тебя вопросы на несколько статей.
Попробуй посмотреть готовое решение - https://github.com/davejamesmiller/laravel-breadcrumbs или познакомься с работой https://octobercms.com/

Для наглядности попробуй database драйвер, раз таблица все равно создана (чтобы вручную в редис не ходить). Табличка jobs должна наполняться строчками, 1 строка - 1 отложенная команда.
И проверь ларавел логи.

(я надеюсь ты сам воркер запустил)

А какую оценку ты ждешь? Наверняка ты сам догадываешься, что это все не очень. Для проекта с 6 тривиальными моделями - вообще без разницы.
Все проблемы появляются при усложнении логики.

По поводу количества комментариев - насколько я знаю, в ларавел из коробки нет подходящего функционала, есть решения через объявление отношения, которое по факту возвращает только количество связанных сущностей, но, это такое.
Доставать отдельным запросом - нормальный вариант, только обычно стараются это делать не в контроллере и как-то максимально реюзабельно. А если говорить о больших проектах - так там вообще денормализация БД, запросы COUNT(*) не делают, а следят за счетчиками в коде + кэши и т.п.

Работает - и ладно Все когда-то так начинали.

shift + shift, в окно вписать "current file", открыть configure current file analyze, опустить ползунок до самого низа

Как правило добавляют какой нибудь ComposerServiceProvider и добавляют туда
https://laravel.com/docs/5.6/providers
https://laravel.com/docs/master/views#p … a-to-views
View::share

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

Blade - простой шаблонизатор. Долгое время бэкенд и фронтенд были связанными. На текущий день нет необходимости в разработке в том-же духе, бэкенд и фронтенд легко разделяются. Все ситуативно, кому как кажется лучше.
Популярный фронтенд фреймворк, который так-же продвигается и "ларавером" - Vue.js. Принцип его взаимодействия с бэкендом такой-же, как и, практически, везде - rest-like api.

какая ошибка?
Вижу только синтаксическую

Было

$purcases = DB::table('purchases')
            ->whereNull('tracker_number')
            ->whereDate('created_at','=', Carbon::today()->toDateString())
            ->join('goods', function ($join) {
                $join->on('purchases.good_id', '=', 'goods.id');
                ->where('goods.test_product','=','0');
            })
            ->get();

Надо

$purcases = DB::table('purchases')
            ->whereNull('tracker_number')
            ->whereDate('created_at','=', Carbon::today()->toDateString())
            ->join('goods', function ($join) {
                $join->on('purchases.good_id', '=', 'goods.id')->where('goods.test_product','=','0');
            })
            ->get();

Для наглядности перенес одну строку

Да, вполне такое может происходить.

Зависит от разных факторов. Чем больше всего - тем лучше.
Для начала надо выяснить в чем затык.

Вот 3 параметра, которые очень тесно связаны:
1 - Потребление приложением ОЗУ на 1 пользовательский запрос
2 - Время обработки одного пользовательского запроса
3 - Нагрузка на сервер (например для расчета можно учитывать количество запросов в минуту).

Простыми подсчетами на пальцах можно предположить, чего не хватает и в какую сторону "апгрейдится".

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