jazzus

$admin->notify(new Message());
следом за юзером или в классе нотификации добавить к MailMessage

public function toMail($notifiable)
{
    return (new MailMessage)
        ->cc('admin@example.com')
        ->markdown('mail');
}

https://laravel.com/docs/8.x/notifications#mail-no...

Разницу подскажет Ларавел если не прописывать ключевики. Можно прописать неверные ключевики в hasOne/belongsTo отношениях и будет все работать. Но отношения будут составлены неверно.

Есть 2 отличия.

Техническое

При user hasOne/hasMany phones Ларавел ожидает, что this id модели (User) будет равен user_id в Phone
При phone belongsTo user Ларавел ожидает что this user_id модели (Phone) будет равен id модели в User

Главный здесь юзер т.к. его ид есть в модели Phone, а phone_id в модели User нет. Поэтому User hasOne Phone, а Phone belongsTo User.

Логическое

Правильно: Юзер имеет один телефон. Юзер имеет много телефонов. Телефон принадлежит юзеру.
То что телефон имеет юзера это сейчас часто встречается, но логически неверно)

Короче. В user прописываем hasOne phone/hasMany phones. В Phone belongsTo user.

В программировании можно какие угодно "бест практики" выдумывать в бесконечных вариациях. Я бы не смотрел на эти изобретения. В доках все понятно написано. Http тесты тестируют http запросы и больше ничего, список ассертов приведен и тд. Тесты не пишут для бест практик и "покрытия", их пишут, чтобы они тебе были нужны как разработчику, фиксировали нужный функционал и работали. А не тесты ради тестов. По структуре все просто - одинаковые объекты, конфиги и тд (как, например у него здесь везде дублируется primaryPost) - в setUp тест класса если во всех тестах или выносится в TestCase/трейты и дальше тесты. Каждый запускается с нуля, за редким исключением прописываются зависимости через @depends. И тесты нужно писать до разработки(тдд). Иначе это будет фигня, а не тесты. Или скорее всего не будут т.к. "покрывать" существующий функционал это очень утомительно и неинтересно. В отличие от тдд, с которым разработка легка и приятна.

whereHas

Product::where('category_id', 5)
    ->whereHas('shops', function ($query) {
        $query ->whereHas('mapPoints', function ($query) {
           $query->where('city_id', 10);
        });
})
->with(...)
->get();

with аналогично, запрос можно вынести в scope см документацию.

DB::table('sessions')
    ->select('last_activity')
    ->whereDate('last_activity', today())
    ->get();

но если просто посчитать то коллекцию создавать не нужно (count на запросе)

Есть ли способ код в модели раскидать по разным классам сгруппировав по общему смыслу но чтобы они были все одной моделью?

Трейты.

но разницы нет что Auth::user() что $this->getUser();

разница есть. В первом случае я понимаю что получу авторизованного юзера. Во втором получу какого-то юзера непонятного. А если открою метод и увижу Auth::user() будет фейспалм)

сыт репозиториями бесполезными

Ну так это ООП. Пока проект простой смысла нет. Потом усложнится чутка и смысл появляется.
Вообще вопрос абстрактный и без кода бесполезный. Т.к. что-то в моделях, что-то в сервисах, а дофига чего в других Ларавел классах, которые часто не используют.

в старой версии
factory(User::class)->create();
в новой
User::factory()->create();

Устанавливаем пакет jenssegers/agent

Создаем мидлварь IsRobot c кодом

if (!(new Agent)->isRobot()) {
    abort(404);
  }
return $next($request);

Добавляем мидлварь к файлу роутов в RouteServiceProvider

Route::middleware('web', 'isRobot')
...

В http тестах findorfail проверяется максимум assertNotFound. Это логично. Http запрос ничего про php код/Ларавел не знает и знать не должен. Если нужно тестировать код, тогда нужно писать юнит тесты.