Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Strategies controller spec to strategy request spec #1859

Merged
merged 6 commits into from
Oct 3, 2020

Conversation

andrew-schutt
Copy link
Collaborator

@andrew-schutt andrew-schutt commented Oct 2, 2020

Description

This refactors the tests associated with the StrategiesController to use RSpec request type tests instead of controller

More Details

Couple things of note:

  • I used the built-in Rails routes helpers
  • Instead of include_context :logged_in_user -> before { sign_in user } is used
  • I eliminated some of the before blocks but could bring them back (I prefer explicitness 😸 )
  • Added the ability to set :focus on a test for running only the test focused.
  • Moved tagged above print_reminders as tagged is a route in the controller vs an include in the controller

Corresponding Issue

#1815 <- parent issue
#1840 <- directly related to this refactor


Reviewing this pull request? Check out our Code Review Practices guide if you haven't already!

Copy link
Contributor

@tyler-wel tyler-wel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me 🤔 pretty long spec lol

One thing I personally like to use is subject
https://www.betterspecs.org/#subject

What are your opinions on it?

@andrew-schutt
Copy link
Collaborator Author

andrew-schutt commented Oct 3, 2020

👋 @tyler-wel thanks for reviewing! 😄

Yeah, I did not realize how long of a spec I was signing up to refactor 😆

In regards to subject, I am not familiar with it at all. Do you have an example of the usage within this spec?

@tyler-wel
Copy link
Contributor

tyler-wel commented Oct 3, 2020

👋 @tyler-wel thanks for reviewing! 😄

Yeah, I did not realize how long of a spec I was signing up to refactor 😆

In regards to subject, I am familiar with it at all. Do you have an example of the usage within this spec?

Yaa, I did the same thing at first before switching which spec I assigned myself to 😂

I personally used subject in my refactor of reports_spec and my current implementation of comments spec here #1861 (even though I personally didn't use betterspecs it { is_expected.to } 🤔 maybe I need to go back and change mine lol)

it 'assigns @strategies' do
get strategies_path, params: { search: 'test' }
expect(assigns(:strategies)).to eq([strategy])
Copy link
Contributor

@tyler-wel tyler-wel Oct 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% sold on assigns matcher for request specs, but I guess it really is no problem, because there are other render/data expectations in this context 🤔

I've always believed it's best to just test the input and output for each possible case. But I guess it isn't hurting anyone still being there 🤷 lol ... especially if we're not rendering json... I guess that's one valid way to check that the data was actually assigned...hmmmm TIL, actually kinda useful huh

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah in this article that @bennpham linked in the original issue, it says that assigns and assert_template is deprecated. Is there another way to check for the value of instance variables?

Copy link
Contributor

@tyler-wel tyler-wel Oct 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned to someone else on Slack, one way to check is check the actual response body (in the case of json) and confirm the returned items are what's expected.

expect(JSON.parse(response.body['some_id']).to eq(expected_value)

For html expectations I'm a little more rusty, as most of my experience is with JSON apis

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used the strategy in that article in which I expect an attribute to be included in the body of the response.

julianguyen
julianguyen previously approved these changes Oct 3, 2020
Copy link
Member

@julianguyen julianguyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking this on! :D Great work!

Everything looks good to me but I'm curious whether the tests for "assigns @strategies" can be tested without assigns / is truly necessary.

let(:user) { create(:user) }
let(:strategy) { create(:strategy, user: user) }

describe '#index' do
let(:strategy) { create(:strategy, name: 'test', user: user) }

context 'when the user is logged in' do
include_context :logged_in_user
before { sign_in user}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!!

it 'assigns @strategies' do
get strategies_path, params: { search: 'test' }
expect(assigns(:strategies)).to eq([strategy])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah in this article that @bennpham linked in the original issue, it says that assigns and assert_template is deprecated. Is there another way to check for the value of instance variables?

spec/spec_helper.rb Show resolved Hide resolved
@andrew-schutt
Copy link
Collaborator Author

I will get the assigns checks cleaned up quickly as well (today 10/3) before we merge

@julianguyen julianguyen merged commit 19d3066 into ifmeorg:main Oct 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants