ты чо, серьезно expose не тестишь?

нет, я не пишу на рельсе ?

так при чем тут TDD?

ну типа мне надо проверку что контроллер чето там expose

нет, я не пишу на рельсе ?

в рельсе нет expose

я про ханами же ну.

тьфу, экшон

ну, если честно, то не, я не юзаю это

потому что тупо смысла не вижу

но я с удовольствием послушал бы доводы за

ну, если честно, то не, я не юзаю это

а как ты во вьюшку прокидываешь данные?

ааа

бля

очень плохо

короче тестирую я все это

очень плохо

что?

да я о другом подумал

сейчас покажу

короче вот так, но это пиздец не круто и надо бы переписать https://github.com/ossboard-org/ossboard/blob/master/spec/web/controllers/tasks/index_spec.rb#L10

о, лол, 9 месяцев тестам

короче, это не правильные тесты

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

> доставание в отдельный функциональный объект ??

я не понимаю почему я просто в юните expose проверить не могу

причем тут объект

там может быть params.errors

а это чисто логика экшона

я не понимаю почему я просто в юните expose проверить не могу

да, ты в логике проверяешь, что оно там что-то держит

и хочу нормальный матчер

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

если у меня экшон вообще не expose то мне напишет undefined метод.

Не информативно ни разу.

ну, там беда в том, что надо мутировать экшен, а потом тестировать его

объясни.

Мы же только call его и все.

ну смотри, ты как тестируешь все это: action.call action.posts

call мутирует action объект, создает все геттеры

expect action to define_method(:posts) ?

ну

потом уже expect(action.send(;posts)).to eq posts

call мутирует action объект, создает все геттеры

разве? я думал заполняет.

мы вообще инстанс экшона получаем через call.

так заполнение и есть мутация

мы вообще инстанс экшона получаем через call.

не, мы через call получаем его результат

ну учитывая что оригинального объекта у нас не было

мы его получаем а не мутируем.

Class.call -> instance

возможно мы о разном говорим, но call вернет массив данных + "заполнит" (замутирует считай) все expose геттеры

аа, точно

Class.call -> instance

class.new -> instance instance.call -> [staus, env, body] + instance.posts

забыл, сорян

мало практики пока что.

ну как бы вот так выглядит экшен let(:action) { described_class.new }

мало практики пока что.

да все норм, не переживай

так вот

усе, молчу

я лох и апазроился.

ты натолкнул на хорошую идею

ты натолкнул на хорошую идею

давай говори.

ты натолкнул на хорошую идею

можно поковыряться и посмотреть на уровне класса какие expose геттеры нужно будет сделать и написать матчер типо: expect(action).to build_exposes(:posts, :users, etc)

но я хз, стоит ли или нет

я правда все еще не понял чем мой матчер плох

как мне кажется, тупо избыточен

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

о котором я уже год думаю

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

адок

ERROR: S client not available

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

у меня есть идея тестировать АСТ от dry-v, но что-то пока руки не доходят проверить

большинство кейсов valid? / invalid

и наверное expose свои ошибки

ну как бы да

только проблема в том, что делать, когда у тебя схема на 20+ строк

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

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

матчером тестировать

берем самый распространенный кейс и на него матчер.

матчером тестировать

каким?

который напишем конечно же!

ну а как он выглядеть должен?

ну а как он выглядеть должен?

обычный тест на валидации

как shoulda matchers какойнить

ну а как он выглядеть должен?

https://github.com/mcorp/shoulda-hanami Нашел

ну хз

но можно посмотреть, спасибо!

Ребят, очень интересная ошибка в продакшене стала появляться. Мы можем сбилбидть какую-то сущность, также сбилдить для нее нестед атрибуты, потом вызывать на ней update! и запись будет создана. Но в продакшене очень часто при подобном раскладе вылетают EROR: null value in column "word_id" violates not-null constraint / PG::NotNullViolation: ERROR: null value in column "word_id" violates not-null constraint Куда копать?

word - это нестенд сущность, и т.к. она не персистед, то айдшников нет. Но они же и не нужны, ведь update! сделает create!

Продублирую сюда, ребзя Всем привет! Nick Sutterer (не без помощи @davydovanton) добрался до Питера, поэтому идём его сегодня гулять. Стартуем в 19.00 в Pitas'e (Невский 65). Возможно мы потом двинем в какой-нибудь бар, так что следите за перемещениями в телеграм-чатике: t.me/saintprug

а кто это

word - это нестенд сущность, и т.к. она не персистед, то айдшников нет. Но они же и не нужны, ведь update! сделает create!

word_id в базе non null

он либо должен позволять null, либо туда должно что тописаться

И что? У меня же происходит создание, откуда у меня возьмется id при создании.

а кто это

автор Trailblazer

спасбо

оч. позитивный чел оказался

И что? У меня же происходит создание, откуда у меня возьмется id при создании.

значит меняй бизнеслогику. Делай в миграции что word_id может быть пустым

хотя с nested сущностями я считай что не работал

значит меняй бизнеслогику. Делай в миграции что word_id может быть пустым

id у сущности не может быть пустым, это глупости.

id у сущности не может быть пустым, это глупости.

в зависимости от логики, у post вполне может отсутствовать author_id.

Но я с nested сущностями мало работал.