Shane M. wrote:
Hi
Just giving cucumber a trial with a Rails application and was wanting
some feedback on what I did for my project token that is a system
generated value …
Scenario: Register new project
Given I am logged in
And I am on the new project page
When I fill in “Title” with “My project title”
And I fill in “Description” with “My project description”
And I press “Create”
Then I should see “My project title”
And I should see “My project description”
And “Project” “token” should have a value
Then /^"(.)" "(.)" should have a value$/ do |model, attribute|
model = controller.instance_variable_get("@#{model.downcase}")
model.send(attribute).should_not be_nil
end
This verifies that @project.token is set. If you are using active
record, then you can probably be fairly certain that the value is stored
in the database. If that is what you need to verify for the customer,
then that is fine.
However, customers don’t (or shouldn’t) care about the backend stuff
like ActiveRecord objects and database records. For that reason, I’d be
more inclined to make sure the project token was displayed on the
screen–that is something the customer interacts with and should care
about. So that would mean a matcher that is something like this:
Then /^"(.)" "(.)" should have a value$/ do |model, attribute|
response.body.should =~
/<div\s[\w="’]*id="#{model.downcase}_#{attribute}">#{model}#{SOME_REGEX_THAT_MATCHER_YOUR_TOKEN}/m
end
I haven’t tested that, so it is probably broken. But the point of the
regex is to match a div with the id model_attribute (change this if you
set ids with a different convention) and it should have the contents
“Token MYTOKEN”.
If you do this, you are verifying what the customer actually sees, which
i generally find preferable to verifying some backend thing like a
record being written to the database.
However, sometimes all you care about for a particular feature is that
it is written to the database. For example, I have an app where users
can send each other messages. I have two separate Scenarios for sending
and receiving. In sending Scenario I verify that there is a db record
with certain attributes. In the receiving Scenario, I start by creating
that same db record, and then I verify what the receiver should see in
the UI.
I hope that helps. I’m not a perfect tester, so I look forward to
someone else’s comments!
Paul