Мне смущается что у меня будет такая проблема
{
{'Model': Samsung},
{'Model': Samsung}
}
Образно говоря нету целостности данных это раз. Ибо в одном переименовываем самсунг, в другом он остается.. Вторая проблема, это когда будет делаться фильтр на сайте, мне нужно получить все значения, но при этом уникальные. Что тоже накладные расходы. Вот и ломаю голову. Перечитал кучу статей и рекомендуют вместе EAV юзать jsonb
Дмитрий, ну насколько я знаю Unit тесты не должны делать запросы по http, к базе и т.д. Наверное надо проверить что приходят нужные поля. Что правильный токен. И всё это дело сохраняется
Дмитрий, проблема происходит на моменте выборки. Это несколько десятков тысяч моделей. А обработка идёт в другом месте. Поэтому и никак чанк использовать не могу. В момент обработки толку нет от чанка. Ибо уже всё выбрано и работает это чудо 20-30 секунд
Дмитрий, я не знаю как применить chunk или cursor. По той причине, что в одной месте у меня вызывается метод, $jobs = $this->getCurrentJobs();.
а этот метод уже находиться в другом месте(в нём запросы) и там все данные обрабатываются, причем этот метод ещё и с другим сотрудничает. Как тут чанк использовать не ясно
N, да я так и планирую) но там надо связать около 8 таблиц и думаю чистый sql быстрее отработает. В идеале бы найти решение на Eloquent. Например чтобы он не в обьекты складывал выборку, а в массив
camradee, этому есть обьяснение. Пространства имен создаются на этапе компиляции в байт код, а не во время выполнения. Поэтому в момент выполнения кода так происходит.
Tokenchik, Отрывок из книги.Обычно зависимость - это интерфейс, который имеет несколько реализа-
ций. Использование реальных реализаций этого интерфейса во время unit-
тестирования - плохая идея, поскольку там могут проводиться те самые опера-
ции ввода-вывода, замедляющие тестирование и не дающие провести тести-
рование этого модуля в изоляции. Прогон unit-тестов должен быть быстр как
молния, поскольку запускаться они будут часто и важно, чтобы разработчик
запустив их не потерял фокус над кодом. Написал код - прогнал тесты, еще
написал код - прогнал тесты. Быстрые тесты позволят ему оставаться более
продуктивным, не позволяя отвлекаться. Решение в лоб задачи изоляции
класса от зависимостей - создание отдельной реализации этого интерфейса,
предназначенного просто для тестирования.
Так вот суть в том, чтобы точечно проверить текущий класс на его функциональность. Моки удодно делать на основе общего интерфейса. Всё мокать не нужно. Но если ваш класс работает с апи, бд, большим обьемом данных. То такая зависимость это плохо.
Цель теста проверить текущий класс на соответствие требований. А какие данные настоящие или фейк это не важно.
Unit Test - модульное решение. Ваш класс можно считать как отдельный , независящий от другого мира. Он не должен знать сам по себе внешние данные и зависеть от них. Суть этих тестов именно проверит функциональность модуля
Могу с уверенностью сказать, что для однотипной фабрики не стоит использовать switch !В его случае именно такая. Все типы это Компоненты наследованные от общего интерфейса. Дурной том в такой случае использовать switch. Если был фабричный метод, ок согласен. Но не тут.