This PR is based on the branch on PR #41 that bumps the Illuminate package version.

Laravel has a global from feature when sending emails, this is a feature that lets you specified the name and email address that will be used for the from field in all emails that the application sends when no from gets specified in the message.,

This PR adds support for that global from functionality.

Okay so bear with me on this one! I only added the minimum required necessities to get this test to pass. If you check out this branch and change getMailer to return $this->mailer ?: MailThief::getFacadeRoot() then you'll see this break.

Let me know if I didn't follow naming conventions, style guide, etc!

I find myself in situations where other messages may have been sent after the one that I'm interested in making an assertion about. I can continue to have these locally, but they should be of more general use to others.

In particular, this should help with #53. The assertion methods may easily be rewritten to take advantage of these methods to become more general in which email gets matched.

Pulling in the entire Laravel Framework causes issues when trying to use this package in a Lumen application. These incompatibilities can be avoided by explicitly requiring only the necessary sub-packages, namely illuminate/mail and illuminate/view.

I have tested this with a fresh Lumen installation as well as an existing Lumen application.

Hey, I just wanted to point out a breaking change in laravel v5.5 that causes this package to no longer function. The signatures for at least the queue(), onQueue(), and queueOn() functions has changed from laravel v5.4.

• https://github.com/illuminate/contracts/blob/5.4/Mail/MailQueue.php#L16 vs.
• https://github.com/illuminate/contracts/blob/5.5/Mail/MailQueue.php#L14

In laravel v5.5 only Mailables can be queued now:

• https://github.com/illuminate/mail/blob/5.5/Mailer.php#L351-L358

I believe the solution will be rather simple:

• Update your composer.json in the next release to require ^5.5 of the illuminate dependencies.

"require": {
    "illuminate/mail": "^5.5",
    "illuminate/view": "^5.5"
},

• Update the method signatures on MailThief object to match the MailQueue contract changes
• Update any associated tests for queues to only test queueing Mailables

If you need any assistance with a PR, I'd be happy to help. However, it is hard to tell how active this repo is until I post this. So for now, I'll just resort to logging test emails and disable usage of this package.

I use Sendgrid to send out our mail. One feature they allow is sending certain headers to categorize mail or send other options. To set the headers I have to get the underlying swift message, which of course means I cannot use MailThief. However it would also be great to be able to check for certain headers during our tests. Do you think this is functionality that should be added? If so I could look into stubbing that out. Obviously the whole SwiftMailer would be too extensive, but would headers be a feature we would want to be able to fake some implementation for?

Hi,

When trying to test my password reset emails I get this error:

A request to [http://xxxxxxxxxxxxxxx/password/email] failed. Received status code [500].

Caused by
 Symfony\Component\Debug\Exception\FatalThrowableError: Type error: Argument 1 passed to App\Http\Controllers\Auth\PasswordController::Illuminate\Foundation\Auth\{closure}() must be an instance of Illuminate\Mail\Message, instance of MailThief\Message given

All other email testing is fine. It seems that mailthief doesn't play nice with Illuminate/Foundation/Auth/ResetsPasswords.php.

I noticed today that MT was failing out on HTML character codes when doing the ->contains() assertion.

Seeing as Laravel's tools (this was using notifications) default to rendering character codes should that be looked at? It would just be a matter of wrapping the "Contains" assertion in the e() helper function.

Hey,

I have the following in my test:

$this->seeMessageFor($user->email);
$this->seeMessageWithSubject('Reset Password');
// Make sure the email was sent from the correct address
$this->seeMessageFrom(config('mail.from.address'));

However, the seeMessageFrom leads the the error:

Error: Call to a member function first() on null
/Users/lukasoppermann/Code/fs-cms/vendor/tightenco/mailthief/src/Testing/InteractsWithMail.php:63
/Users/lukasoppermann/Code/fs-cms/tests/functional/LoginPageTest.php:96

Line 96 is $this->seeMessageFrom(config('mail.from.address')); however, the address from config is correct and even replacing it with a string does not help.

Removing this line makes the test pass.

I just noticed that if I dd($this->lastMessage()) the from is null. But in the log file, there is a from part.

Any ideas?

Hello!

In my Laravel 5.2 app I created a little trait with some helpers, to call MailThief asserts in the same way as the see() and seeInDatabase() methods. Perhaps it could be interesting to add helpers like this to your package?

use MailThief\Facades\MailThief;

trait InterceptsEmail
{
    /** @before */
    protected function interceptEmails()
    {
        MailThief::hijack();
    }

    protected function seeEmailFor($email)
    {
        $this->assertTrue(
            MailThief::hasMessageFor($email),
            sprintf('No e-mail was sent to "%s".', $email)
        );

        return $this;
    }

    protected function seeEmailSubject($subject)
    {
        $this->assertEquals(
            $subject, MailThief::lastMessage()->subject,
            sprintf('The e-mail subject does not match "%s".', $subject)
        );

        return $this;
    }

    protected function seeInEmailSubject($subject)
    {
        $this->assertContains(
            $subject, MailThief::lastMessage()->subject,
            sprintf('The e-mail subject does not contain the text "%s".', $subject)
        );

        return $this;
    }
}

This allows me to run tests like this:

use Illuminate\Foundation\Testing\DatabaseMigrations;

class RegistrationTest extends TestCase
{
    use DatabaseMigrations;
    use InterceptsEmail;

    /** @test */
    public function a_user_receives_an_activation_mail_after_registering()
    {
        $userData = [
            'first_name' => 'John',
            'last_name' => 'Doe',
            'email' => '[email protected]',
        ];

        $this->visit('/nl/login')
            ->type($userData['first_name'], 'first_name')
            ->type($userData['last_name'], 'last_name')
            ->type($userData['email'], 'email')
            ->check('agree')
            ->press('Register');

        $this->see('Thanks')
            ->seeEmailFor($userData['email'])
            ->seeInEmailSubject('Activate')
            ->seeInDatabase('activations', $userData);
    }
}

This pull request resolves issues with the latest commit to support Laravel 5.5.

Please reference the most recent comments in Issue #76 to see a detailed explanation on how this fixes the current release for laravel v5.5.