question.feature

# Given the following tests

Given I create an invitation for "[email protected]"
And I create an invitation for "[email protected]"
When I send my invitations
Then I should have sent emails to:
  | email            |
  | [email protected]    |
  | [email protected] |

# If triggering the sending of the emails is synchronous, but sending the emails is asynchronous
# what is the appropriate level of testing for this feature?

Although if it must be async, then is send timeliness important? I'd say it is. Say you have an NFR to send within 30s, then you can use TimeCop to mock time, jump ahead 30s, and assert that the message was added to the send queue.

Nik, I'm not sure we want to add a queue just for testing purposes. We'd be adding a proxy to a system that works.

Benson, #NTD4Life.

Kyle, get that title fixed?

If the email sending returned a promise to you, you could block on the promise.

How about a separate test of sending of emails with an item in a queue. Here you just need to test that it generates a message on the queue.

Here's the small example written in node (our use case)

# Observer

User.on 'afterSave', (user) ->
    UserMailer.welcome_email(user).send()

# Model

User.emit 'afterSave', user

This entire flow is tested in Unit tests,
User saved, event emitted - done
Event emitted, function called - done
function called, emails sent - done

The question is, from an integration test, where we have a system that diverts processes to a new thread (desired flow).

Should we add a wait? - easy, but prone to race conditions

Break the test up into smaller pieces? - When we get as small as we need to, to be able to know when processes has completed, we will have duplicated the spec test.

Add an eventually step which gives an assert n seconds to be true?

Well it's written in coffeescript not node, but you get that.

I agree with @alexkehayias, send() should return a promise in this case. The API should support this after all - what if the SMTP server is down?