Андрей Клюев: Вероятно Вы правы, если вдуматься, то кажется тестировать надо на отсутствие значения, а не на наличие. Спасибо, попробую подумать в эту сторону.
В системе может быть предусмотрено, что связь необязательно может задаваться через hasOne. Например где-то есть Фабрика, производящая автомобили, либо автомобиль это агрегат из нескольких моделей либо вообще абстракция. hasOne это метод в лоб - "есть запись - есть связь". хочется чего-то более изящного.
Андрей Клюев: я не тестирую связь моделей, я тестирую, что конкретное свойство возвращает конкретный тип значения - в этом смысл юнит-теста. Как я установлю это свойство - это уже на самом деле дело десятое и в этом конкретном тесте я могу замокать сеттер и тестировать сеттер отдельно.
Да, пожалуй Вы правы, нет необходимости заранее загружать связь. В конечном счете мне хотелось бы понять, как можно изолированно протестировать getCar() без создания записи в таблице car. Я ожидаю, что свойство $this->car вернет экземпляр Car. $this->hasOne вызывает статический файндер следовательно ищет запись в БД.
почему "извращений"? Если я точно знаю, что у водителя есть ровно одна машина и хочу в момент инициализации водителя инициализировать экземпляр машины, почему я не могу сделать это через конструктор или init(), а должен создавать выделенный метод? Может я чего-то не понимаю?
Спасибо за ответ. Цель - например создать условия для изоляции в юнит-тестах. Я могу вызывать файндеры в динамическом контексте и в тесте подменять модель Car на мок - это даст мне возможность избежать создания записей в БД при юнит-тестах. ($this->carClass->findOne(...)). Джойнить в более сложных запросах - я думаю, что сложные запросы лучше делать через методы DAO.
дима кубитский я ни в чем не пытаюсь вас убедить. Очевидно, что вы не смотрите на код, как на бизнес-актив, коим он в сущности является. Без этого любой спор относительно стилистики не имеет смысла.
дима кубитский напрасно думаете, что не проблема. Посчитайте, сколько у вас времени занимает рефакторинг одного метода переименованием + тесты, умножьте на количество методов, умножьте на стоимость трудочаса разработчика, получите весьма солидную сумму и это затраты, которых изначально можно избежать без особого труда. Вы ведь понимаете, что коммерческий продукт нельзя просто взять и отрефакторить контекстной заменой?
Посторонним В.: это ваша архитектура конечно, вам виднее, но кажется подобное наследование одиночек ни к чему хорошему не приведет. Я могу только догадываться, но похоже такой архитектурой вы хотите получить несколько заменяемых реестров один из которых хранилище в куке. Если это так - вам лучше смотреть в сторону паттерна инъекций зависимостей.
