y
Интерфейс? Как Authenticatable
class TestForPackage
User extends \Illuminate\Foundation\Auth\UserSize: a a a
2020 September 26
y
а там уже короче в конфиге сам разраб выбирает каую модель юзать
А
Что люди делали до того как сделали ларавель? При чем тут твой вопрос?
Думали головой
y
только еще конф поправить это для того чтобы не ломать тесты) чтобы они не были зациклены на App\user
A
Тебе нужен интерфейс, с которым ты будешь работать
y
Тебе нужен интерфейс, с которым ты будешь работать
это да)
A
А какой класс его будет реализовывать - дело второе
y
а нормальная практика в тестах создавать миграцию для пакета? то есть есть главные миграции но для тесты отдбелные нужно сделать в папке tests
P
то есть грубо говоря с помощью докера и трусервера мощного, можно разделить все на сервисы по контейнерам верно ?
Да, можно важно что бы каждая из частей которые планируется масштабировать могла работать отдельно друг от друга. Но в случае с laravel архитектура уже предполагает такую возможность.
А
а нормальная практика в тестах создавать миграцию для пакета? то есть есть главные миграции но для тесты отдбелные нужно сделать в папке tests
Нет
y
Нет
а как тогда создавать в тестах грубо говоря главную модель юзера? а потом логинить ее и тд
y
и потом будут взаимодействия с этой моделью другими пользователями
А
а как тогда создавать в тестах грубо говоря главную модель юзера? а потом логинить ее и тд
Что за главная модель?
y
я без таблицы что - то представить не могу
y
Что за главная модель?
ну типа Auth
А
Чем не главная не устроила?
А
ну типа Auth
Что ты тестируешь?
y
Чем не главная не устроила?
потому что отдельный пакет и когда ты заливаешь на гитлаб) тесты не пройдут так как отстуствует App\User
y
поэтому я думаю создать в тестах специальную миграцию для дефолтного модели юзера так сказать)
y
чтобы тесты не крошились)