[LRUG] Testing email invitations with Cucumber

Ian Kynnersley iankynnersley at gmail.com
Wed Jan 30 01:18:50 PST 2013


Hi Chris,

Thanks, that's very useful.

As you suggest, there are no non-technical people on our project who are
getting involved with the writing of our cucumber features. I still like
the exercise of trying to think about the problem in plain language (in the
problem domain) as well as the benefits of end-to-end and regression tests
so I still think there is a lot of value in using Cucumber here.

There are definitely places where the solution has crept into the features
we have and you're right to point out that that is causing some of the
confusion.

It sounds like essentially you are saying that the approach is the right
one - test the full multi-user journey in a single scenario but that it
will make much more sense to do so once we take ourselves away from the
solution and we describe that journey using the right language.

Cucumber is reasonably new to both of us on the project (one of us is
totally new to Rails) so this kind of feedback is very useful.

Thanks
Ian



On Tue, Jan 29, 2013 at 8:54 PM, Chris Parsons <chris.p at rsons.org> wrote:

> Hi Ian,
>
> I'd start off by taking a step back. Try asking yourself the following
> questions:
>
> * Who are the people reading this feature who can't read code?
>
> 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.
>
> * When reading my feature, am the words to do with the project domain
> itself, or the solution I'm applying?
>
> 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.
>
> 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:
>
> Given I'm a pilot who's been selected for the secret test flight programme
> When I recommend another pilot, Maverick, who I think could help the
> programme
> Then Maverick should receive an invitation detailing the programme
> When he accepts the invitation
> Then he should be informed that he has accepted
>
> 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.
>
> Matt Wynne wrote a useful post recently which might help further:
> http://blog.mattwynne.net/2013/01/17/the-problem-with-solutions/
>
> HTH
> Chris
>
> --
> Chris Parsons
> chrismdp at gmail.com
>
> Training at: http://bddkickstart.com
> Blog: http://chrismdp.com
> Twitter: http://twitter.com/chrismdp
>
> On 29 Jan 2013, at 19:47, Ian Kynnersley <iankynnersley at gmail.com> wrote:
>
> Hi Graham,
>
> Thanks for your very helpful response. I think you're right that testing
> the email contents is a job for a unit test.
>
> 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:
>
> Given I have been invited
> When I visit the "accept invitation" page
> Then I should see ....
>
>
> 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).
>
> And thanks for the Gist. It clarifies it nicely.
>
> Cheers
> Ian
>
>
> On Tue, Jan 29, 2013 at 7:15 PM, Graham Ashton <graham at effectif.com>wrote:
>
>> On 29 Jan 2013, at 18:35, Ian Kynnersley <iankynnersley at gmail.com> wrote:
>>
>> > We are using email_spec (https://github.com/bmabey/email-spec) to do
>> the email interaction stuff and it seems to work well but the scenarios end
>> up pretty tortuous.
>>
>> I really don't think there's any need to test all that in one test, or
>> with cucumber.
>>
>> 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.
>>
>> Why are you using cucumber? Are any non technical people on your team
>> eager to read your tests?
>>
>> This is how I do it:
>>
>> - functional tests on my controller that checks an email gets sent
>>
>> - functional tests on my mailer to check they contain the right links
>>
>> Here's a gist with the very tests in:
>>
>> https://gist.github.com/4666549
>>
>> 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".)
>>
>> > 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.
>>
>> I wouldn't decide where to send the email from based on whether or not I
>> can persuade my testing framework to see it.
>>
>> 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.
>>
>> Better to make it explicit, and control when the email is sent yourself.
>>
>> 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.
>>
>> What I'm trying to say is "there's nothing wrong with sending it in the
>> controller".
>>
>> > Has anyone done this? It is pretty standard behaviour. Does anyone have
>> any recommendations?
>>
>> [dons flame proof suit]
>>
>> 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?
>>
>> 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).
>>
>> --
>> Graham Ashton
>> Founder, The Agile Planner
>> http://www.theagileplanner.com | @agileplanner | @grahamashton
>>
>>
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
>
> --
>
> Ian Kynnersley
> http://iankynnersley.co.uk | +44 (0) 7973 420 829 |
> http://twitter.com/kpopper
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> --
> Chris Parsons
> chris.p at rsons.org
> http://twitter.com/chrismdp
> http://pa.rsons.org
>
>
>
>
>


-- 

Ian Kynnersley
http://iankynnersley.co.uk | +44 (0) 7973 420 829 |
http://twitter.com/kpopper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130130/557d0698/attachment.html>


More information about the Chat mailing list