Rails%203%20In%20Action

Locking down states
With this added to the permissions hash, your scenario will move a little further
toward success. When you rerun it, it will complain that it can’t find the Open state
from your select box:
And I select "Open" from "State"
No such option 'Open' in this select box.
Ah, not a problem! This means that the Open state isn’t yet defined in your test database.
You need to create this state in the Background for this feature. You can do this
by adding the following line at the bottom of the Background:
Given there is a state called "Open"
When you rerun this scenario using bin/cucumber features/assigning_permissions
.feature:74, 4 it will now pass:
1 scenario (1 passed)
22 steps (22 passed)
That’s good! Now admins are able to assign the “Change states” permission and users
are able to see and touch the State select box on the comment form if they have this
permission.
This is a great halfway point before you go diving into the final stage of this particular
set of features to run your Cucumber features and specs to ensure that nothing is
broken. Let’s run rake cucumber:ok spec now; you should see that all your tests are
passing:
53 scenarios (53 passed)
568 steps (568 passed)
# and
34 examples, 0 failures, 17 pending
Yay! Everything is in working order, which means you can commit and push these
changes to GitHub:
git add .
git commit -m "Only users with the 'change states' permission
➥can change states"
git push
The final piece of your states puzzle is to stop the state parameter from being set in
your CommentsController if a user passes it through and doesn’t have permission to
set states. First, you’ll investigate how a user can fake this response. Afterward, you’ll
write a controller spec that duplicates this and ensures that the state isn’t set.
4 If you get no scenario and no steps running for this feature, are you sure you’re running the right line? Check
to make sure you’re running line 75, not 74, which is now a blank line.
281