Writing tests can be hard. Should I mock? Perhaps I should spy? Or maybe there is a built in fake()
for this?
Writing tests for mail can be even harder. Enter Laravel’s Mail Fake. Use that at the beginning of your test, do your heavy lifting, then run some assertions against the fake. It is extremely helpful to verify that mail gets sent out and peek at the mail to ensure it got sent to the right person. As a sidenote, a little known plus with faking mail is that it will disable mail from sending accidentally during tests. You never want to be the one who sent out a few hundred emails accidentally… but back to the subject at hand.
But faking mail can only take you so far. How do you test the email body contains the correct string? What about that custom header? Or even the subject? Those kinds of details need to be tested, but can’t be faked. Right Harry?
Say hello to Mail Intercept!
Mail Intercept for Laravel is a new way of testing mail by intercepting, not faking, email so we can dissect it, turn it upside down, and inspect everything.
Under the hood, it is quite simple in that it forces the mail driver to be an array pushing all those emails into memory. We then grab those emails and run assertions on them! That’s it, pretty simple really!
But we didn’t want to stop there. We wanted it to be really easy to run assertions against those emails to check for specific things. Here are the assertions available to you as of this writing:
1$this->assertMailSentTo($to, $mail); 2$this->assertMailNotSentTo($to, $mail); 3$this->assertMailSentFrom($from, $mail); 4$this->assertMailNotSentFrom($from, $mail); 5$this->assertMailSubject($subject, $mail); 6$this->assertMailNotSubject($subject, $mail); 7$this->assertMailBodyContainsString($content, $mail); 8$this->assertMailBodyNotContainsString($content, $mail); 9$this->assertMailHasHeader($header, $mail);10$this->assertMailMissingHeader($header, $mail);11$this->assertMailHeaderIs($header, $value, $mail);12$this->assertMailHeaderIsNot($header, $value, $mail);
You will notice that each assertion accepts, as the last parameter, a $mail
object. Where does that come from you might ask? Let’s look at a simple test to answer that question.
1namespace Tests; 2 3use App\Jobs\SomeJobThatSendsMail; 4use Illuminate\Foundation\Testing\WithFaker; 5use KirschbaumDevelopment\MailIntercept\WithMailInterceptor; 6 7class MailTest extends TestCase 8{ 9 use WithFaker;10 use WithMailInterceptor;11 12 public function testMail()13 {14 $this->interceptMail();15 16 $email = $this->faker->email;17 18 SomeJobThatSendsMail::dispatchNow($email);19 20 $interceptedMail = $this->interceptedMail()->first();21 22 $this->assertMailSentTo($email, $interceptedMail);23 }24}
The first thing to notice is the use of the WithMailInterceptor
trait. This pulls in the ability to intercept and makes available our mail assertions.
Just like faking mail, we must call the $this->interceptMail()
before mail gets sent.
After the mail is sent we need to retrieve the freshly sent mail. We grab these with $this->interceptedMail()
. This will return a collection of sent mail. And since it is a collection, we can use the first()
method to grab the only email we sent.
Now we can run all the assertions against that mail object. If instead we need to run assertions against multple emails, we can use the each()
method to loop through them.
We’ve included a good starting point for assertions. However, if there aren’t enough for your liking, the mail object is an just an instance of Swift_Message
with all of its available methods. Head over to the Swift Mailer Docs for all available methods.
Interested in using this test suite in your project now? Head over to Mail Intercept on Github, pull it into your project with Composer and start intercepting and testing mail with confidence!
0 comments:
Post a Comment
Thanks