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

Попробую развернуть, а дальше решай как знаешь.

1) Если у тебя есть метод, к которому ты задаешь вопрос "я хочу протестировать, что этот метод делает вот это,  вот это, а еще вот это и это" - скорее всего у тебя хреновый метод и он требует рефактора
2) писать тесты, чтобы проверить работу фреймворка, на мой взгляд, равносильно переносу воды в решете.  Как бы можно, но смыла почти нет.

Теперь о том, как это делал бы я

просто этот пример у коллеги увидел)

1) $users = UserProxy::model()->with([
   'products' => function ($query) {
       //
   }
]);

Вот этот код - это не зона ответственности контроллера. Это сервис / репозиторий.

2) return Resource::collection($users->get()); -
это фича тесты контроллера. Такое есть смысл только для фиксации контракта АПИ. Можно, но спорно. Я бы подумал, нужно ли на это тест в пакете. Уж лучше из приложения тест тогда сделать интеграционный, но не на уровне пакета.

"писать тесты, чтобы проверить работу фреймворка, на мой взгляд, равносильно переносу воды в решете.  Как бы можно, но смыла почти нет."

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

Соответственно, если мы хотим протестировать контроллер, то мы делаем:
- быстрый тест с моком на проверку вызова нужного нам метода (если очень хочется)
- быстрый тест с моком коллекции на предмет фиксации контракта

Если мы хотим протестировать сервис / репозиторий - то мы тестируем не контроллер, а сервис. Но если у тебя та весь код - это Model::get() - то я хз зачем это тестироввть. это функционал фреймворка

спасибо)

Пакет - штука, которая может легко переноситься между приложениями, верно?

$users = UserProxy::model()->with([
   'products' => function ($query) {
       //
   }
]);

В каких ситуациях этот метод может работть не верно именно по причине ТВОЕГО кода в пакете?

Я вижу причины:
- отсутствие корректных данных / связей / схемы БД (но если у тебя там нет миграций именно под твою специфику, то у тебя их никогда и не будет)
- код фреймворка работает не корректно

если например указана модель которая не существует в проекте, как вариант, так же если в ней нет подключенного трейта пакета вот два варианта)

если ты пытаешься тащить код, завязанный на схему, которой у тебя нет  - это плохой код

супер, сделай обработку в try catch и кинь кастомный exception

и сделай тест - если в конфиге не валидный класс,  которого нет, то у тебя будет выдан ожидаемый тобой exception ДО вызова кода запроса в БД

спасибо за информацию)

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

если у тебя нет ответа на вопрос - что именно ты хочешь протестировать - ты не напишешь хороший тест

есть простой ответ:
1) твой пакет не содержит полный объем данных
2) ты пытаешься написать интеграционный тест
3) интеграционный тест требует полный объем данных

ну есть варианты развития событий, например при добавления продукта в корзину если у пользователя нет определнной роли он это сделать не может и сервер должен вернуть 500 код) типа этого мне надо тестить типа разные варианты

тут есть некоторое противоречие, которое тебя сбивает, а ты упорно пытаешься пролезть нпролом

если у тебя пакет решает вопрос с добавлением товаров в корзину,  то я вижу одно из двух:
- либо этот же пакет должен все знать о правах доступа (что странно)
- либо вопрос с правами доступа должен решаться на другом уровне