У меня в проекте пришел АА и парень разраб в довесок. И вот заказчик просит поменять дизайн админки. Поставили тему какую то. Красивей не стало)

индекс коллекции в АА делается быстрее

Мы кстати тут уже говорили на тему простых решений. Пришли к выводу что лучше взять CMS

я даже поставил и попробовал october

очень классная штука для Список статей Список постов список тем

Чо как тебе?

Доволен

я тогда весь вечер поковырял

гибкая, CMS для разраба

Это CMF по сути

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

да я помню, ты говорил

да, там laravel inbuilt, очень круто.

http://ichef-1.bbci.co.uk/news/624/cpsprodpb/17FB7/production/_92713289_66661ec0-c3a7-4259-9260-b98d49b25a2f.jpg

да видел) Вообщем если придется вдруг сайт визитку собирать

Я знаю на чем делать

Вопрос в том, что лара врятли shared хоста поддерживает и деплоить придется на VPS

я пока еще не умею в простые решения :(

а почему нет?

у меня знакомый _вроде бы_ на шареде держал

на форуме видел что с5й ларой чтото не так

кстати у них даже свой капистрано пыховский есть)

все выдернули с рельсы

http://rocketeer.autopergamene.eu/

Но на офф сайте вроде даже и говорят, что 5я ларавель это совокупность лучших наработок в том числе из рельсы

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

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

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

все логику надо вытаскивать в классы и тестить отдельно

Мокать контроллер тоже так себе идейка

если мокаешь контроллер то тест не интеграционный получается.

что значит мокать контроллер

Тогда как тебе поведение надо тестировать

прокидываешь парамы, тестишь результат

поведение какое? Контроллер не должен содержать никакого логического поведения в идеале

что значит мокать контроллер

class Controller def index Api.fetch end end expect(Api).to receive(:fetch)

апи должно быть не в контроллере

Мы тестируем что контроллер ведет себя как ожидается

апи должно быть не в контроллере

А где? ?

хз, в классе third party api, во view object

ахаха

где хочешь

контроллер вот @pages = { params for view }

где хочешь

тебя переклинило

ок)

Если у меня экшен завист от реалтаймового запроса к апишке, то где я этот вызов делаю если не в контроллере?

Если у меня экшен завист от реалтаймового запроса к апишке, то где я этот вызов делаю если не в контроллере?

в сервис-объекте?

В сервисе делаешь

да

а Api.fetch это не своеобразный сервис объект?

Хорошо, зачем нужен контроллер если все в сервис объекте?

классно у тебя сервис вызывается Service.method end

прям как надо

а сорян

криво прочитал

ну ты не мокаешь контроллер

ты тести сервис

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

что должен вызваться сервис

я не понял, Михайло, какую проблему ты пытаешься щас решить :)

проблему отсутствия проблем

Я пытаюсь сказать что тест апишки должен быть там, где это апишка лежит

в отдельном сервисе

а наверное так и просходит

А в контроллере ты тестишь только что должно быть в обьектах, которые ты возвращаешь во вью. Никакой логики. Никаких вызовов

Хорошо, зачем нужен контроллер если все в сервис объекте?

он принимает запрос, и отдает результат

А в контроллере ты тестишь только что должно быть в обьектах, которые ты возвращаешь во вью. Никакой логики. Никаких вызовов

ну это тоже перебор

Контроллер получил парам. Отдал в логику. Получил результат, отдал во вью

ERROR: S client not available

ну это тоже перебор

кому как удобно. Но я предпочитаю в контроллер ничего не пихать

Тестить сложнее

черно-белое все какое-то

кто тебе сказал что я в контроллере тестирую апишку

Ты сказал что из контроллера вызываешь стороннюю апи и мокаешь

я в контроллере ее дергаю, и тестирую все в сборе. Апишка отдельно юнит тестом тестируется

Я мокаю http ответ апишки но не сам класс

Ну вот

то есть ты за повторил то о чем я говорю, но с намеком что я сказал чтото не то

Я к тому что лучше лишний раз проверить все интеграционно чем где то обломаться.

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

И в совокупности оно отработает нормально

до тех пор пока ты все в сборе не запустишь и наткнешься на конфиг/глобальный стейт или еще какую фигню

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

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

потому что конфиг кривой.

в solid первый принцип единственной ответственности есть. И если постараться его соблюдать, не отвалится ничего

ага, принцип единственной ответственности и Rails

ну да ну да.

Один AR сразу весь solid сожрал

За рельсу пусть отвечает DHH

ахаха

я буду отвечать за свои буквы)

красавчеки, вы так даже истину родите скоро

без сарказма

не ну просто забавно слушать про солди тогда как почти каждый рельсовик активно юзает AR

красавчеки, вы так даже истину родите скоро

Ты про здравый смысл чтоли?

каждый рельсовик не пишет AR

не ну просто забавно слушать про солди тогда как почти каждый рельсовик активно юзает AR

да, это выглядит лицемерно, правда?)

каждый рельсовик не пишет AR

А теперь процитируй где я это утверждал

нигде

да, это выглядит лицемерно, правда?)

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