question.feature

# Given the following tests

Given I create an invitation for "jon@shake.com"
And I create an invitation for "justin@lab49.com"
When I send my invitations
Then I should have sent emails to:
  | email            |
  | jon@shake.com    |
  | justin@lab49.com |

# 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?

Basically, triggering the event that would build and send an email is synchronous. But actually building and sending is asynchronous. The current approach is to just add And I wait 1 second before the assertion.

Is there a better approach? What is that better approach?

:5
O
And jobs are processed

In our system job processing is asynchronous.

i think you should test it synchronously .. like make a fake queue and do "jobs are processed" like arjun said which just clears the queue

whitespace

don't write tests

@benson +1

Why is the message building and sending async in the first place? Surely the building and adding to a queue is synchronous? If you need to assert it hits a third party service, you just mock that.

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?