Skip to content

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

Merged
merged 11 commits into from
Apr 5, 2023
Merged

Adding feature specs to project #3

merged 11 commits into from
Apr 5, 2023

Conversation

bpurinton
Copy link
Contributor

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.

Copy link
Contributor

@jelaniwoods jelaniwoods left a 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.

Comment on lines 49 to 55
before do
@movie = Movie.create(
title: "My title",
description: "My description"
)
visit "/movies/#{@movie.id}"
end
Copy link
Contributor

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.

Copy link
Contributor Author

@bpurinton bpurinton Apr 5, 2023

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.

Copy link
Contributor

@jelaniwoods jelaniwoods Apr 5, 2023

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.

Copy link
Contributor Author

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.

@bpurinton
Copy link
Contributor Author

@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.

@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 rails grade up to this point, some changes in wording / structure of the tests won't be too jarring?

@jelaniwoods
Copy link
Contributor

@bpurinton

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.

Yes it's definitely a large guide. It was very recently updated, so I wasn't sure if you knew about it.

raghubetina just wants something to track progress and these tests might all change in the near future.

Understood. Then you can largely ignore my style comments then. The exception is the authenticity_token test, doesn't pass for me when I update the form to use form_with. Was that passing for you?

@bpurinton
Copy link
Contributor Author

bpurinton commented Apr 5, 2023

Understood. Then you can largely ignore my style comments then. The exception is the authenticity_token test, doesn't pass for me when I update the form to use form_with. Was that passing for you?

Oddly no, and I spent too long trying to dig into it, I'm working on a draft PR here and have removed the authenticity_token test in that case. Not going to spend all day trying to figure that out, just going to drop it and move on for now.

I know that sounds a little sketchy, but the point of this specific project is that they hand-write the authenticity_token code. So it's good to check for that, and actually good that this doesn't pass with form_with.

@bpurinton bpurinton requested a review from jelaniwoods April 5, 2023 19:42
@jelaniwoods
Copy link
Contributor

I know that sounds a little sketchy, but the point of this specific project is that they hand-write the authenticity_token code.

Understood. It should be fine for this project then. LGTM 🚀

@bpurinton bpurinton merged commit 58b59de into main Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants