Rails%203%20In%20Action

Sending ticket notifications
Then they should see "updated the Release date ticket" in the email body
And the email should contain 2 parts
And there should be a part with content type "text/plain"
And there should be a part with content type "text/html"
When you run this feature with bin/cucumber features/ticket_notifications
.feature, you’re notified that the two steps you’ve just used are undefined:
Then /^the email should contain two parts$/ do
pending # express the regexp above with the code you wish you had
end
Then /^there should be a part with content type "([^"]*)"$/ do | arg1 |
pending # express the regexp above with the code you wish you had
end
The email_spec gem doesn’t provide any steps for this, so you must craft your own.
The gem does provide some helper methods that you can use. You should define
these steps in a file separate from features/step_definitions/email_steps.rb, because the
next time you run the email_spec generator, it will overwrite this file. Let’s instead
put them in features/step_definitions/app_email_steps.rb and define them like this:
Then /^the email should contain (\d+) parts$/ do |num|
current_email.parts.size.should eql(num.to_i)
end
Then /^there should be a part with content type "([^"]*)"$/
do |content_type |
current_email.parts.detect do |p|
p.content_type == content_type
end.should_not be_nil
end
In the first step here, the current_email method comes from email_spec and represents
the currently opened email. You open this email with the “Then alice@ticketee
.com opens the email” step in your scenario. This object is a Mail::Message object,
which represents an email object. You check in this step that the email contains the
number of parts you say it should contain, and convert the num variable to an integer
using to_i because it comes in from the step definition as a String object.
In the second step, you iterate through the parts to the email, using detect to
return the first part in parts, which matches the condition inside the block you specify.
You don’t care at this stage what order the parts appear in (that’s something the different
email clients will deal with), but you do care that there’s more than one part.
When you run your feature using bin/cucumber features/ticket_notifications
.feature, you see that the first of your two newest steps fails:
And the email should contain 2 parts
expected 2
got 0
So your scenario expected to see two parts, but got none. Why not even one? Well, the
normal flavor of emails don’t come with multiple parts, because the text is part of the
323