Comment tester ActionMailer deliver_later avec rspec

Si vous trouvez cette question, mais utilisez ActiveJob plutôt que de simplement DelayedJob sur son propre, et sont à l'aide de Rails 5, je vous recommande la configuration de ActionMailer dans config/environments/test.rb:

config.active_job.queue_adapter = :inline

(c'était le comportement par défaut avant de Rails 5)

Je vais ajouter ma réponse, car aucun des autres était assez bon pour moi:

1) Il n'est pas nécessaire de se moquer de l'Expéditeur: les Rails se fait déjà pour vous.

2) Il n'y a pas vraiment besoin de déclencher la création de l'e-mail: cela consomme du temps et de ralentir votre test!

C'est pourquoi, dans environments/test.rb vous devez avoir les options suivantes set:

config.action_mailer.delivery_method = :test
config.active_job.queue_adapter = :test

De nouveau: ne livrez pas vos e-mails à l'aide de deliver_now mais toujours utilisation deliver_later. Qui empêche les utilisateurs d'attente pour l'efficacité de la livraison de l'e-mail. Si vous n'avez pas sidekiq, sucker_punch, ou de toute autre production, il suffit d'utiliser config.active_job.queue_adapter = :async. Et soit async ou inline pour le développement de l'environnement.

Compte tenu de la configuration suivante pour l'environnement de test, vous e-mails seront toujours mis en file d'attente et jamais exécuté pour la livraison: cela empêche de se moquant d'eux et vous pouvez vérifier qu'ils sont correctement mis en file d'attente.

En vous tests, toujours diviser le test en deux:
1) Une unité de test pour vérifier que le mail est mis en file d'attente correctement et avec les paramètres corrects
2) Un test unitaire pour le mail pour vérifier que le sujet, l'expéditeur, le destinataire et le contenu sont corrects.

Donné le scénario suivant:

class User
  after_update :send_email

  def send_email
    ReportMailer.update_mail(id).deliver_later
  end
end

Écrire un test pour vérifier l'e-mail est correctement mis en file d'attente:

include ActiveJob::TestHelper
expect { user.update(name: 'Hello') }.to have_enqueued_job(ActionMailer::DeliveryJob).with('ReportMailer', 'update_mail', 'deliver_now', user.id)

et écrire un essai séparé pour votre e-mail

Rspec.describe ReportMailer do
    describe '#update_email' do
      subject(:mailer) { described_class.update_email(user.id) }
      it { expect(mailer.subject).to eq 'whatever' }
      ...
    end
end

• Vous avez testé exactement ce que votre e-mail a été mis en file d'attente et pas un emploi générique.
• Votre test est rapide
• Vous besoin de pas se moquant de

Lorsque vous écrivez un système de test, n'hésitez pas à décider si vous voulez vraiment envoyer de mails là, car la vitesse n'est pas question que beaucoup plus. Personnellement, j'aime à configurer les éléments suivants:

RSpec.configure do |config|
  config.around(:each, :mailer) do |example|
    perform_enqueued_jobs do
      example.run
    end
  end
end

et affecter la :mailer attribut pour les tests ont été fait je veux envoyer des e-mails.

Pour en savoir plus sur la façon de configurer correctement votre e-mail dans les Rails de lire cet article: https://medium.com/@coorasse/the-correct-emails-configuration-in-rails-c1d8418c0bfd

Une meilleure solution (que monkeypatching deliver_later) est:

require 'spec_helper'
include ActiveJob::TestHelper

describe YourObject do
  around { |example| perform_enqueued_jobs(&example) }

  it "sends an email" do
    expect { something_that.sends_an_email }.to change(ActionMailer::Base.deliveries, :length)
  end
end

La around { |example| perform_enqueued_jobs(&example) } s'assure que les tâches en arrière-plan sont exécutés avant de vérifier les valeurs de test.

Un moyen simple est:

expect(ServiceMailer).to(
  receive(:new_user).with(@user).and_call_original
)
# subject

Cette réponse est un peu différent, mais il peut aider dans les cas comme un nouveau changement dans les rails de l'API, ou un changement dans la façon dont vous souhaitez vous faire livrer (comme l'utilisation deliver_now au lieu de deliver_later).

Ce que je fais la plupart du temps est de passer un mailer comme une dépendance à la méthode que je suis en train de tester, mais je ne passe pas un mailer de rails, j'ai plutôt passer un objet qui va faire les choses dans la "voie que je veux"...

Par exemple si je veux vérifier que je suis d'envoyer le bon mail après l'inscription d'un utilisateur... je pourrais le faire...

class DummyMailer
  def self.send_welcome_message(user)
  end
end

it "sends a welcome email" do
  allow(store).to receive(:create).and_return(user)
  expect(mailer).to receive(:send_welcome_message).with(user)
  register_user(params, store, mailer)
end

Et puis, dans le contrôleur, où j'ai appeler cette méthode, je voudrais écrire le "réel" de la mise en œuvre de cette mailer...

class RegistrationsController < ApplicationController
  def create
    Registrations.register_user(params[:user], User, Mailer)
    # ...
  end

  class Mailer
    def self.send_welcome_message(user)
      ServiceMailer.new_user(user).deliver_later
    end
  end
end

De cette façon, je sens que je suis en train de tester que je suis d'envoyer le bon message, à la droite de l'objet, avec les bonnes données (arguments). Et je suis dans le besoin de la création d'un objet très simple qui n'a pas de logique, juste la responsabilité de savoir comment ActionMailer veut être appelé.

Je préfère le faire parce que je préfère avoir plus de contrôle sur les dépendances que j'ai. Il s'agit du formulaire-moi un exemple de la "Inversion de la dépendance principe".

Je ne suis pas sûr si c'est à votre goût, mais il est une autre façon de résoudre le problème =).

Pour les dernières Googlers:

allow(YourMailer).to receive(:mailer_method).and_call_original

expect(YourMailer).to have_received(:mailer_method)