-
Notifications
You must be signed in to change notification settings - Fork 73
Adding feature specs to project #3
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
Conversation
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.
@bpurinton nice work! I realize, I've been assuming these tests are supposed follow best practices and not do the unconventional readable appdev 1 style specs, is that correct?
If not, there are more recent notes about the hacks I did for the AD1 specs you can reference.
spec/features/1_basic_spec.rb
Outdated
before do | ||
@movie = Movie.create( | ||
title: "My title", | ||
description: "My description" | ||
) | ||
visit "/movies/#{@movie.id}" | ||
end |
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.
Same feedback as the previous PR. Best practices suggest that you should prefer using let
when creating variables that are used across multiple examples.
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.
@jelaniwoods I understand using let
for instance variables / database objects and can make that change. But my use of before
here and elsewhere was to DRY up the visit
requests in each describe
block. Is there a "correct" way to do that? Or should I just put the visit
in each it
block?
Update
I did some research, and looked at specs for other projects. Looks like I'm best off just re-using visit
in each it
block, so going to do that now.
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.
Is there a "correct" way to do that? Or should I just put the visit in each it block?
From what I understand the only issue with before
is that you shouldn't define variables in that block. I think the preferred approach is something like this:
let(:movie) do
Movie.create(title: "My title", description: "My description")
end
before do
visit "/movies/#{movie.id}"
end
See shared examples.
But again, if these tests don't have to follow "best practices", no need to worry about this too much.
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'm just following your style guide in this case and putting visit inside each block.
@jelaniwoods I have looked through the notes already, but it's a lot to process when I'm just trying to get some simple, functional tests. These Phase II specs are a rush job at the moment, @raghubetina just wants something to track progress and these tests might all change in the near future. I think it's better to leave any inconsistencies compared to Phase I tests for a refactoring later on. In theory, since the students have become very familiar with |
Yes it's definitely a large guide. It was very recently updated, so I wasn't sure if you knew about it.
Understood. Then you can largely ignore my style comments then. The exception is the |
Oddly no, and I spent too long trying to dig into it, I'm working on a draft PR here and have removed the I know that sounds a little sketchy, but the point of this specific project is that they hand-write the |
Understood. It should be fine for this project then. LGTM 🚀 |
These are just some basic feature tests mostly focused on visiting pages and checking content. There are a couple of more advanced tests relevant to this project to test for the presence of authenticity token fields and for proper DELETE requests.