потому что BDD

потому что assigns это антипаттерн в BDD.

а кто говорит о BDD?

в rspec-rails есть свой инструментарий

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

нужно подавать запрос и смотреть ответ

верно

а что если меняется внешнее состояние

по запросу?

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

те юнит тест на контроллер?

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

ну ты понял

нет у тебя эта логика из контроллера выносится.

это не работает так

может в идеальном сфеерическом мире

с срущими радугой единорогами

все контроллеры тонкие

вся трава голубая

а небо зеленое

Всмысле BDD это же расширение подхода TDD

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

Всмысле BDD это же расширение подхода TDD

не совсем

или прочесть кэш?

что за суперстейт контроллера такой.

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

например интерфейс к редису

хотя это херовый пример

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

подробней. Как вопрос ответ тестировать?

там действительно лучше делать слой абстракции

но по твоей логике

лазать в базу данных

для проверки состояния

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

как юнит тесты к котроллеру прикрутить. Это же тоже функция ее тоже надо тестировать

уже зашквар

не сказал бы

ты же не контроллер тестируешь

в рейлс мире есть понятие

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

функциональных тестов

ну вот я пишу тест describe 'GET new' do it 'render :new template' do get :new expect(response).to render_template(:new) end it 'assigns new Achievement to @achievement' do get :new expect(assigns(:achievement)).to be_a_new(Achievement) end end А потом уже реализую данный функционал

это как называется?

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

как он это сделает и какие роешения примет не так важно.

ну вот я пишу тест describe 'GET new' do it 'render :new template' do get :new expect(response).to render_template(:new) end it 'assigns new Achievement to @achievement' do get :new expect(assigns(:achievement)).to be_a_new(Achievement) end end А потом уже реализую данный функционал

А чо GET new и не просто .new?

ты же метод контроллера тестируешь.

/warn

Dima has been warned (1/5)

@Fedcomp гугл мне подсказал, как вы все советивали) БЫл вопрос нашел ответ

как реализовать

работает же)

assigns выпилили потому что это считается антипаттерном.

Ты конечно можешь это юзать, т.к ты разработчик.

а что использовать?

убедись что контроллер изменил модель/вернул ответ который ты ожидаешь.

@Fedcomp что значит антипаттерном

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

антипаттер - это практики считающиеся дурными с точки зрения определенной группы лиц.

По каким либо причинам которые были озвучены.

а

грубо говоря - паттерн - подход/шаблон поведения, антипаттерн соответственно плохой подход.

ERROR: S client not available

а чем assigns так плох, я читал всю переписку так и не понял

тем что ты тестируешь как написан контроллер

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

Иначе потом при любом переписывании могут падать тесты.

Иначе потом при любом переписывании могут падать тесты.

это нормально

это нормально

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

ты не путай интеграционные тесты

https://www.pluralsight.com/courses/test-driven-rails-rspec-capybara-cucumber я просто начал изучать эти курсы

когда вся система для тебя блекбокс

там так делают, видимо не совсем хорошие курсы(

и "функциональные" (ака юнит тесты)

но вообще

я согласен

там так делают, видимо не совсем хорошие курсы(

capybara точно не тестирует как шаблон внутри написан.

что assigns - это херовый подход

нужно смотреть сам ответ

ты не путай интеграционные тесты

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

а не какой шаблон будет рендерится/или подобное

https://www.pluralsight.com/courses/test-driven-rails-rspec-capybara-cucumber я просто начал изучать эти курсы

cucmber => фтопку

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

require 'rails_helper' feature 'home page' do scenario 'welcome message' do visit("/") expect(page).to have_content('Welcome') end end

Если реально нужно тестировать шаблоны/верстку плюс общие интеграционные тесты, то тут капибара рулит.

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

this

это уже копибара же

тестируй сам ответ

@t3hk0d3 gпо такому принципу ? feature 'home page' do scenario 'welcome message' do visit("/") expect(page).to have_content('Welcome') end end

заходить на страницу и смотреть

заходить на страницу и смотреть

ага.

Проверяешь что при нажатии кнопки происходят какие то вещи например.