<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Ian,<div><br></div><div>I'd start off by taking a step back. Try asking yourself the following questions:</div><div><br></div><div>* Who are the people reading this feature who can't read code?</div><div><br></div><div>If there are such people, these features are for them, and need to be written as such using their language - just write down pretty much exactly what they're telling you. If aren't any on this project, then the reason you're writing them is to get your head out of the code and think about the project itself without using technical words at all.</div><div><br></div><div>* When reading my feature, am the words to do with the project domain itself, or the solution I'm applying?</div><div><br></div><div>I would suggest that the terms 'logged in', 'subject', 'contents', 'sign out', 'clicks', 'links', 'accept page', and even 'user' are all to do with your solution, rather than the project domain itself, which is why it's hard to get away from the implementation in your feature.</div><div><br></div><div>Without knowing your domain, I can't easily help further, but let's assume you're inviting people to participate in test flying fast jets. I might write this scenario like this:</div><div><br></div><div>Given I'm a pilot who's been selected for the secret test flight programme</div><div>When I recommend another pilot, Maverick, who I think could help the programme</div><div>Then Maverick should receive an invitation detailing the programme</div><div>When he accepts the invitation</div><div>Then he should be informed that he has accepted</div><div><br></div><div>You could implement these steps in any way you chose underneath the hood (email, IM, secure messaging of some sort), which gives you a huge amount of flexibility about how you implement them to cover the intent of the scenario. You've still got an end-to-end test covering the whole journey, the benefit of the regression testing, and good documentation for your non-technical stakeholder.</div><div><br></div><div>Matt Wynne wrote a useful post recently which might help further: <a href="http://blog.mattwynne.net/2013/01/17/the-problem-with-solutions/">http://blog.mattwynne.net/2013/01/17/the-problem-with-solutions/</a></div><div><br></div><div>HTH</div><div>Chris</div><div><br></div><div>--</div><div>Chris Parsons</div><div><a href="mailto:chrismdp@gmail.com">chrismdp@gmail.com</a></div><div><br></div><div>Training at: <a href="http://bddkickstart.com">http://bddkickstart.com</a></div><div><div>Blog: <a href="http://chrismdp.com">http://chrismdp.com</a></div><div>Twitter: <a href="http://twitter.com/chrismdp">http://twitter.com/chrismdp</a></div></div><div><br></div><div><div><div>On 29 Jan 2013, at 19:47, Ian Kynnersley <<a href="mailto:iankynnersley@gmail.com">iankynnersley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Graham,<div><br></div><div>Thanks for your very helpful response. I think you're right that testing the email contents is a job for a unit test. </div><div><br></div><div style="">I would still like to have cucumber coverage for the "invited user clicks on the link in the email". However, I guess we could validate that the link in the email is correct in the unit test and then have a cucumber feature that says: </div>
<div style=""><br></div><div style="">Given I have been invited</div><div style="">When I visit the "accept invitation" page</div><div style="">Then I should see ....</div><div style=""><br></div><div style=""><br></div><div style="">
I also agree that for this app, the controller is probably the right place for these emails to be triggered (although better would be to wrap them in some sort of invitation class).</div><div style=""><br></div><div style="">And thanks for the Gist. It clarifies it nicely.</div>
<div style=""><br></div><div style="">Cheers</div><div style="">Ian</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 29, 2013 at 7:15 PM, Graham Ashton <span dir="ltr"><<a href="mailto:graham@effectif.com" target="_blank">graham@effectif.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 29 Jan 2013, at 18:35, Ian Kynnersley <<a href="mailto:iankynnersley@gmail.com">iankynnersley@gmail.com</a>> wrote:<br>
<br>
> We are using email_spec (<a href="https://github.com/bmabey/email-spec" target="_blank">https://github.com/bmabey/email-spec</a>) to do the email interaction stuff and it seems to work well but the scenarios end up pretty tortuous.<br>
<br>
</div>I really don't think there's any need to test all that in one test, or with cucumber.<br>
<br>
The first half of your steps are checking that an email gets sent to the right person. The second half just check that the email's subject is correct, and that it has a specific link in it. That sounds a lot like unit testing to me.<br>
<br>
Why are you using cucumber? Are any non technical people on your team eager to read your tests?<br>
<br>
This is how I do it:<br>
<br>
- functional tests on my controller that checks an email gets sent<br>
<br>
- functional tests on my mailer to check they contain the right links<br>
<br>
Here's a gist with the very tests in:<br>
<br>
<a href="https://gist.github.com/4666549" target="_blank">https://gist.github.com/4666549</a><br>
<br>
I've done it this way on a few apps, and have never had any trouble. (The "an" and "the" blocks are from nutrasuite; think of them as "describe".)<br>
<div class="im"><br>
> Does this indicate the email should be sent from somewhere else (in the model or maybe a creator class) so that my "Given I have been invited" step will automatically generate the email.<br>
<br>
</div>I wouldn't decide where to send the email from based on whether or not I can persuade my testing framework to see it.<br>
<br>
I'd think about when the email should be sent. For example, if you used an after_create callback on your model you wouldn't be able to create an invitation at the console without sending an email out. If you were doing some admin (e.g. fixing an invitation that didn't get delivered for some reason), that could cause a bunch of unwanted messages to get sent out without you realising.<br>
<br>
Better to make it explicit, and control when the email is sent yourself.<br>
<br>
You could make a method in the model that creates the invite and sends the email (which would be handy if you wanted to invite somebody from the Rails console), or you could just do it in your controller and manually call MyMailer.my_message(my_model).deliver to send an email from the console, should you need to.<br>
<br>
What I'm trying to say is "there's nothing wrong with sending it in the controller".<br>
<div class="im"><br>
> Has anyone done this? It is pretty standard behaviour. Does anyone have any recommendations?<br>
<br>
</div>[dons flame proof suit]<br>
<br>
I'd suggest you probably don't need to write a full end to end integration test for it. How necessary it is will depend on your app. What are the failure modes? What will the integration test catch that a handful of unit tests wouldn't?<br>
<br>
If you think "should send an email to invite new users" test in my gist is too lax (in the context of my app it isn't - there's only one email that could get sent), you could just tweak it so that it checks that the last email in ActionMailer::Base.deliveries is the correct message (e.g. by checking the subject).<br>
<br>
--<br>
Graham Ashton<br>
Founder, The Agile Planner<br>
<a href="http://www.theagileplanner.com/" target="_blank">http://www.theagileplanner.com</a> | @agileplanner | @grahamashton<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>
<br>Ian Kynnersley<br><a href="http://iankynnersley.co.uk/" target="_blank">http://iankynnersley.co.uk</a> | +44 (0) 7973 420 829 | <a href="http://twitter.com/kpopper" target="_blank">http://twitter.com/kpopper</a>
</div>
_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; ">--<br>Chris Parsons<br><a href="mailto:chris.p@rsons.org">chris.p@rsons.org</a><br>http://twitter.com/chrismdp<br>http://pa.rsons.org<br><br><br><br></span>
</div>
<br></div></body></html>