попробуй моему боссу объясни =)

думаю что есть зависимость от сложности проекта к низкоуровневости фреймворка. проще приложение и проще фреймворк

весело наверное мокать работу с базой когда у тебя AR

типа ларавеля

да понятно, что если вы делаете корп сайт с новостями, абсолютно пофиг дм или ар

прекрасно можно мокать базу, если нужно. вопрос в том, а зачем нужно мокать базу

нормально мокается

у тебя в методе некий User::find(1) как ты это замокаешь?

прекрасно можно мокать базу, если нужно. вопрос в том, а зачем нужно мокать базу

наверное потому что ты пишешь юнит тест?

а зачем тебе писать юнит тест на функционал фреймворка, у которого к тому же свои юнит тесты

попробуй моему боссу объясни =)

для этого у вас есть СТО или тип того)

да уж не все так гладко как кажется

хотя сам сейчас doctrine изучаю. ) пишу пока на laravel. CTO как такового нет. небольшая компания торговая

интернет магазин написали на Laravel+Eloquent.

https://laravel.com/docs/5.4/mocking все мокается, даже Job (Command Bus)

просто стараюсь все на сервисах делать. и норм. и тестируется норм

а зачем тебе писать юнит тест на функционал фреймворка, у которого к тому же свои юнит тесты

в смысле на функционал фреймворка? у тебя есть сервис, внутри которого из базы достается юзер. как мне юнит тестом проверить этот сервис, если там выборка на статических методах?

https://laravel.com/docs/5.4/mocking все мокается, даже Job (Command Bus)

не вижу там моков для моделей

Sergey так ненадо делать статические методы

$flights = App\Flight::where('active', 1) ->orderBy('name', 'desc') ->take(10) ->get();

дока врет?

в смысле на функционал фреймворка? у тебя есть сервис, внутри которого из базы достается юзер. как мне юнит тестом проверить этот сервис, если там выборка на статических методах?

что мешает использовать репозиторий?

И это не проблема AR, это проблема реализации файндера... который, вообще-то, к AR не имеет никакого отношения

Например, Yii во второй версии вынесла файндер в отдельную сущность

$user = new User; $user->username = 'philipbrown'; $user->save(); ок, у меня в методе вот такое используется. юнит тест упадет с ошибкой, как быть с save?

http://www.yiiframework.com/doc-2.0/guide-db-active-record.html#querying-data вот дока yii

что мешает использовать репозиторий?

наверное то что в AR реализациях везде смешаны выборки и модели?

и что? вводи слой репозитория. в котором будет выборки

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

ага.. и в этот репозиторий еще save вынести

и можно называть это дата маппером

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

нет, я не хочу тестировать базу. я хочу протестировать конкретный юнит, не затрагивая сеть и другие сервисы

у нас в отдельных классах все методы выборок, их можно замокать. плюс для тестов мы используем stage server

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

так тестируй, ваще не понмаю в чем проблема... в том, что ты в сервис статикой посажал работу с моделями? ну так это не проблема AR, это твоя архитектура

я тоже не понимаю в чем проблема

$user = new User; $user->username = 'philipbrown'; $user->save(); ок, у меня в методе вот такое используется. юнит тест упадет с ошибкой, как быть с save?

вы игнорируете то что я пишу?

выше сбрасывал линки на доки yii и laravel

где явно описаны примеры выборок

это не я придумал статику делать, это советуют в доке

В доке советуют для начинающих. Ты начинающий?

where не статический метод

ок, допустим сделали репозиторий, туда вынесли все выборки. как быть с транзакциями? персисты и апдейты

where не статический метод

$flights = App\Flight::where('active', 1) а что это тогда?)

В доке советуют для начинающих. Ты начинающий?

а где дока для продвинутых тогда?)

это магия

для продвинутых дока - код

?

а у тебя с твоими потребностями "там вставить, там транзакция" - используй тестовую базу и фикстуры

а правильно ли вообще тестировать на проде?

зачем мне база и фикстуры если мне достаточно будет моков?

Если у тебя такая архитектура, что замена слоя персиста с DM на AR и т.п. сказывается на возможности писать юнит-тесты, то моков тебе будет не достаточно

или у тебя сервис работает формализовано через репу, когда точно известно, какой метод какой набор сущностей вернет, тогда еще можно замокать... или же у тебя в сервисе прямая работа со слоем персиста, и тогда ты задолбаешься делать моки... это все-равно, что поместить прямо в сервисе $em->createQueryBuilder() и удивляться, что трудно тестировать

насчет статических методов из доки: Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.

Ох Laravel на Mockery строит свои тесты Он и статику мокает и приватные методы. Правда там приходится изолированно тесты запускать и страдать, но Mockery успешно вам замокает App\Flight::where

$modelMock = Model::shouldReceive('find') ->with('1') ->andReturn('value');

типа такого

Если у тебя такая архитектура, что замена слоя персиста с DM на AR и т.п. сказывается на возможности писать юнит-тесты, то моков тебе будет не достаточно

как раз после замены на DM простотых phpUnit моков становится достаточно

можно еще трейт подкрутить DatabaseTransactions который после теста откатывает изменения в бд

из коробки

$user = new User; $user->username = 'philipbrown'; $user->save(); ок, у меня в методе вот такое используется. юнит тест упадет с ошибкой, как быть с save?

можно зають Mockery чтобы затестить поведение, для твоего кейса - хз я бы выносил в отдельную штуку, типо UserProvider или еще что-то

как раз после замены на DM простотых phpUnit моков становится достаточно

в какой точке

насчет статических методов из доки: Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.

фасады это немного не то, это обертка над сервисами, а здесь конкретный кейс когда сервис завязан на конкретную реализацию User

ну так where это не статический метод жеж

ERROR: S client not available

Еще раз, проблема не в том, что AR хреновый, проблема в том, что вы завязали сервис на него. В случае доктрины вы, наверняка, репозиторий будете инжектить... и потом его мокать. Что мешает это делать в ларавеле? Да ничего, кроме костности

в доктрине есть такое понятие как репозиторий, и кастомные репозитории расширяющие базовые. а в yii/laravel я такого в принципе не вижу если переход от DM на AR требует отказаться от юнит тестов, то нафиг оно надо? замокать через мокери ты конечно можешь что угодно, еще можно runkit затащить. только вот от этого код не становится лучше

да, но ты хоть понимаешь, что понятие "репозиторий" вообще никакого отнощения к DM не имеет? Это отдельный паттерн

в доктрине есть такое понятие как репозиторий, и кастомные репозитории расширяющие базовые. а в yii/laravel я такого в принципе не вижу если переход от DM на AR требует отказаться от юнит тестов, то нафиг оно надо? замокать через мокери ты конечно можешь что угодно, еще можно runkit затащить. только вот от этого код не становится лучше

откуда такая мысль? от вашего непонимания?

>если переход от DM на AR требует отказаться от юнит тестов, то нафиг оно надо? ...

да, но ты хоть понимаешь, что понятие "репозиторий" вообще никакого отнощения к DM не имеет? Это отдельный паттерн

посмотри на определение этого паттерна у фаулера для начала

и что? ты там увидел слова Data Maper и подвис? ;)

да, но ты хоть понимаешь, что понятие "репозиторий" вообще никакого отнощения к DM не имеет? Это отдельный паттерн

репозитории в доктрине != паттерт репозиторий

репозитории в доктрине != паттерт репозиторий

и в чем отличие?

в доктрине есть такое понятие как репозиторий, и кастомные репозитории расширяющие базовые. а в yii/laravel я такого в принципе не вижу если переход от DM на AR требует отказаться от юнит тестов, то нафиг оно надо? замокать через мокери ты конечно можешь что угодно, еще можно runkit затащить. только вот от этого код не становится лучше

не обязательно отказываться, прост будет разные подходы к тестам

и что? ты там увидел слова Data Maper и подвис? ;)

репозиторий нужен не только для хранения выборок и уменьшения дублирования кода. он предоставляет абстракцию для работы с хранилищем. но в AR у тебя модели и так имеют доступ к хранилищу

тебя никто не заставляет использовать это

не обязательно отказываться, прост будет разные подходы к тестам

мокать можешь что угодно, хоть ядро пхп. но еще раз говорю что код от этого лучше у тебя не станет

и в чем отличие?

паттерт не должен зависеть от реализации. т.е. не должен возвращать например entity или коллекцю доктрины

заменит $model->save() на $repo->add($model) и уже в репе сделай save().

заменит $model->save() на $repo->add($model) и уже в репе сделай save().

в чем профит тогда от AR?

если у тебя выборки в репосе, сохранение тоже в репосе

возьми обычный дата маппер, сделай анемичную модель и радуйся жизни

паттерт не должен зависеть от реализации. т.е. не должен возвращать например entity или коллекцю доктрины

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

в какой точке

В точке инжектирования репозитория и мы инжектим мок репа а не сам репозиторий Тоже и для сохранения сущности.

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

тут мы опять зависим от доменных сущностей доктрины

если у тебя выборки в репосе, сохранение тоже в репосе

а у AR профит один - он проще для простых моделей с простой логикой

тут мы опять зависим от доменных сущностей доктрины

и? репозиторий - это коллекция доменных сущностей

а у AR профит один - он проще для простых моделей с простой логикой

проще чем?

и? репозиторий - это коллекция доменных сущностей

которые не зависят от реализации . тогда да

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

которые не зависят от реализации . тогда да

от реализации чего? ;) репозиторий - это как раз инкапсулирование работы со стораджами

у тебя на каждой модели висит референс к коннекту базы. какая еще инкапсуляция работы со стораджами?

+

+

чо плюс, ты вообще о доктрине говоришь, а сергей про AR :)

Вы тут говорите что не надо пользоватся доками надо что то изобретать чтоб потом не страдать в тестах Но как бы я приду и буду делать по документации в которой статические методы и отсуствие репозиториев

у тебя на каждой модели висит референс к коннекту базы. какая еще инкапсуляция работы со стораджами?

и что? Модели сами что ли в базу ходят? или ты код пишешь этот