Потому что французы не заслужили уважение (гугли мем про "F", если не знаешь)

напиши функционал сам, если имеющееся решение не работает

В контроллере просто выводим юзеров которые указаны в конфиге моего пакета грубо config('package.model')::all() а так как в тесте нет модели App\User я вывести это не смогу так как отсуствует таблица, поэтому я создал просто свой класс User унаследовался от \Illuminate\Foundation\Auth\User + трейт для работы с пакетом добавил,  и в тестах создал миграцию этой таблицы чтобы только при тесте создавалось) есть и другие таблицы но они не зависят от Auth

config('package.model')::all() - классный пакет, просто, блять, надежный пакет

Ты написал, что ты сделал. Я тебе задал вопрос другой - что именно ты хочешь протестировать в своём коде?

там через класс обернуто) я просто так написал тут)

например есть модель Product, есть пивот таблица которая связывает продукты и юзеров, создается отдельная таблица для этого, потом когда пакет заюзали в проекте добавляем в свой класс который наследуется от \Illuminate\Foundation\Auth\User трейт пакета в котором есть методы для работы с ппродуктами, так вот мне это надо покрыть тестами, так как например мне нужно написать банальный тест отдать 5 айдишников юзеров и получить какие то данные например user_id products: []

а из за того что в пакете нет модели App\User я это сделать не могу

покрыть тестами, чтобы покрыть тестами - самая бессмысленная трата времени. Лучше не переводи его и сделай что-нибудь полезное. То есть что ты протестировать хочешь - ты не знаешь, верно понял?

знаю, создаем в пакете модель наследуем ее от \Illuminate\Foundation\Auth\User добавляем трейт создаем миграцию и фабрику в тестах и тестим, это сделать легко просто я хотел узнать есть ли еще какие варианты так как миграцию создавать не хочется как то коряво смотрится

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

ты снова не отвечаешь на мой вопрос. Ты хочешь протестировать работу illuminate и вставку в бд? Ты не доверяешь коду фреймворка и считаешь, что он нестабильно работает и вставка данных может работать не так как надо?
Если так, то тебе надо пушить PR в репозиторий фреймворка, а не твой пакет

Если не так, то тебе НЕ нужно тестировать функционал illuminate и вставку в бд. Согласен?

я хочу проверить работу контроллеров, то есть rest api (Integration tests) написать для этого тесты, но дело в том что у меня есть такая штука как "модель юзера по умолчанию" по умолчанию это App\User а может быть что - то другое, вот и все и для тестов мне нужен класс котроый наследуется от \Illuminate\Foundation\Auth\User для всей фигни из коробки ларавел, а так как такого класса у меня нет, то я создам, и создам для этого миграцию, потому что есть миграции пакеты которые пивот и они ссылаются на эту модель которая указана в конф файле пакете) я хз как еще объяснить)

что именно в работе контроллеров ты хочешь проверить?

давай по другому попробую. Зона ответственности контроллера:
- принять данные
- вызвать сервисы / репозитории
- вернуть данные

что из этих пунктов ты хочешь проверить в своем пакете?

*  тут есть ремарки про request и тд

например вот мтод из контроллера на GET
$users = UserProxy::model()->with([
   'products' => function ($query) {
       //
   }
]);
...code
return Resource::collection($users->get());

UserProxy::model отдает путь к классу который наследуется от \Illuminate\Foundation\Auth\User он указан в конфиге пакета
products это связь (трейт пакета который цепляется к модели laravel проекта к модели юзера)
мне нужно написать тесты чтобы понимать что ресурсы при каких то ситуациях отдают правильный результать, так как у меня нет модели юзера в пакете, мне нужно ее создать, я решил создать по умолчанию любую модель + миграцию чисто в тестах и все и потом юзать, я сюда написал потому что думаю что есть вариант лучше)

и как это правильно сделать хз меня устраивает вариант который я описал но можно же лучше