Rails%203%20In%20Action

Locking down states
Then /^I should not see the "([^"]*)" element$/ do |css|
page.should_not(have_css(css),
"Expected to not see the #{css} element, but did.")
end
Here you use Capybara’s have_css matcher to see if the page has an element matching
the CSS selector, which is passed to this step. You also use RSpec’s ability to specify
a custom message if this assertion fails, returning “Expected to not see the
#comment_state_id element, but did” if this element is visible on the page.
If you run this feature using bin/cucumber features/creating_comments
.feature:42, you see that this step is failing because it is seeing the element:
Then I should not see the "#comment_state_id" element
Expected to not see the #comment_state_id element, but did
Right, now that you’ve got your feature to a good-enough point that it ensures that
you shouldn’t see this field, it’s time to hide it and fix the feature. To do this, you use
the can? method to check that the user has permission to change states for this project.
If the user doesn’t have this permission, then you’ll hide the state field. With this
change, the State select box code in app/views/comments/_form.html.erb will now
look like the following listing.
Listing 10.28 app/views/comments/_form.html.erb
@ticket.state_id %>
Here you use the authorized? method defined in chapter 8 to only display the fields
if the user is authorized to changed the states.
This little change will make your scenario pass because the user you’re signing in
as doesn’t have this particular permission set up. Let’s run it now with bin/cucumber
features/creating_comments.feature:42 to make sure:
1 scenario (1 passed)
10 steps (10 passed)
Good to see, but this view change has definitely broken the scenario in this feature,
which does change the state. You can run this other scenario by running bin/cucumber
features/creating_comments.feature:33; when you do that, you see that it’s
indeed broken:
cannot select option, no select box with id, name, or label 'State' found
You’ve done something similar to this before in chapter 8. Back then, you used a step
that set the current user up with a permission to perform a specific protected action.
This is no different. Let’s write a new step underneath the title of the scenario on line
279