-
Notifications
You must be signed in to change notification settings - Fork 2
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
Rosters #43
Conversation
Need migration and then V/C
Validations need work
Still need a way of adding a user to the rotation who's already in another rotation.
Just need to fix Twilio, and then write specs.
Since that's how we moved the method in question as well
Will do, looks like there are some Rubocop issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor things.
roster_params = params.require(:roster).permit(:name) | ||
roster = Roster.new roster_params | ||
if roster.save | ||
flash[:message] = 'roster has been created.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial capitalization
|
||
def destroy | ||
@roster.destroy | ||
flash[:message] = 'roster and any assignments have been deleted.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial capitalization
def update | ||
roster_params = params.require(:roster).permit! | ||
if @roster.update roster_params | ||
flash[:message] = 'roster has been updated.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial capitalization
user_1 = create :user | ||
user_2 = create :user | ||
user_3 = create :user | ||
user_1 = create :user, rosters: [@roster] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be worth writing a spec_helper method like create_user
which you pass a roster, just to cut down on the repetition between lines here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because there can't be any users without rosters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand your answer.
My question was whether it would be worth writing a method e.g.:
def roster_user(roster)
create :user, rosters: [roster]
end
So that we could cut down on the repetition here, by calling e.g.:
user_1 = roster_user(@roster)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we'd literally never be calling create :user, except to test that it doesn't work without having a roster. My point is there are no users that aren't roster_users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And my point is that the current code is extremely repetitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, there are only a few instances when I want a user to belong to a specific roster, so it's repetitive in that case, but very few.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, well, I felt like I was reading the exact same code a bunch but if that's not the case then whatever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW
grep -r "rosters: \[@roster\]" . | wc -l
gives me 23.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO there's something to be said for WET tests cases. It's great to have total isolation for each example, even if comes at the expense of repetitive LOC.
That being said, if a macro makes sense that that's a way to go here. I think the danger there is that said macro can (and almost always will) grow moving more and more setup logic out of the individual examples making it harder to understand (in the future) why tests fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle that's true. This example is pretty trivial isolation. If this 'macro' fails, we've got bigger problems.
.with @user_ids, Date.today, Date.tomorrow, @starting_user_id | ||
# remove all other instances of roster so 'any instance' definitely | ||
# refers to our @roster instance | ||
Roster.where.not(id: @roster.id).delete_all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK but why are there any if we're not creating them here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when_current_user_is creates a user. Creating a user creates a roster, since there can never be any users unless there are rosters.
expect(Roster.where(id: @roster.id)).to be_empty | ||
end | ||
it 'destroys the roster' do | ||
expect_any_instance_of(Roster) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not a single line?
|
||
describe 'GET #new' do | ||
it 'renders the new template' do | ||
expect(get :new).to render_template :new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird parentheses
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by 'weird'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, never mind, it's not a big deal and Rubocop didn't flag it. Disregard.
end | ||
it 'redirects to the index' do | ||
submit | ||
expect(response).to redirect_to( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not a single line?
spec/factories/users.rb
Outdated
@@ -5,5 +5,6 @@ | |||
sequence(:spire) { |n| n.to_s.rjust(8, '0') + '@umass.edu' } | |||
sequence(:email) { |n| "user#{n}@umass.edu" } | |||
sequence(:phone) { |n| '+1' + n.to_s.rjust(10, '0') } | |||
rosters { [FactoryGirl.create(:roster)] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does one need to say FactoryGirl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, holy brackets, 🦇 👨
spec/factories/assignments.rb
Outdated
@@ -1,6 +1,7 @@ | |||
FactoryGirl.define do | |||
factory :assignment do | |||
user | |||
roster | |||
user { FactoryGirl.create(:user, rosters: [roster]) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does one need to say FactoryGirl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm guess not.
user_1 = create :user, rosters: [@roster] | ||
user_2 = create :user, rosters: [@roster] | ||
user_3 = create :user, rosters: [@roster] | ||
user_1 = roster_user @roster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really no better or worse than before
@@ -1,2 +1,5 @@ | |||
require: umts-custom-cops | |||
inherit_from: .rubocop-no-umts-cops.yml | |||
|
|||
HasAndBelongsToMany: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I like to add comments explaining why we're disagreeing with Rubocop.
In testing your code I reviewed it as well, so I think it's fine for now. I fixed some things I found. What do you think of the tests?