Laravel测试中如何正确断言Mailable的属性（如Subject）？

这个问题我之前也碰到过！核心原因确实是Laravel的Mail Fake在收集邮件实例时，并没有自动执行build()方法——而你在build()里设置的subject等属性，自然就不会被赋值，导致断言时拿到的是null。下面给你两种无需修改业务代码的解决方案：

方法1：在断言闭包中手动执行build() #

这是最直接的方案，只需要在测试的断言回调里先调用$mail->build()，触发Mailable完成所有配置：

Mail::assertSent(RequiresVerification::class, function ($mail) use ($user) {
    $mail->build(); // 执行build方法，加载subject等配置
    return $mail->subject === 'hello' && $mail->hasTo($user->email);
});

为什么hasTo()能正常工作？因为你大概率是在构造函数里直接设置了收件人（比如$this->to($user->email)），或者hasTo()方法本身是直接检查Mailable的收件人集合——这些集合可能在构造阶段就已经被初始化了，而subject是在build()里通过$this->subject()方法设置的，所以必须执行build()才能拿到正确的值。

方法2：扩展Mailable添加自定义断言方法 #

如果你不想在每个测试里都重复写build()，可以给你的Mailable基类添加一个类似hasSubject()的方法，内部自动处理build()的调用：

use Illuminate\Mail\Mailable;

abstract class BaseMailable extends Mailable
{
    public function hasSubject(string $expectedSubject): bool
    {
        $this->build();
        return $this->subject === $expectedSubject;
    }
}

然后让你的RequiresVerification继承这个基类，测试时就可以这样断言：

Mail::assertSent(RequiresVerification::class, function ($mail) use ($user) {
    return $mail->hasSubject('hello') && $mail->hasTo($user->email);
});

为什么不推荐在构造函数里设置subject？ #

你说得完全没错，这种为了测试修改业务代码的做法违背了Laravel的设计规范——官方明确说明所有Mailable的配置都应该放在build()方法里，这样能保持代码的一致性和可维护性，尤其是当你需要根据动态数据（比如用户信息、业务参数）调整邮件内容时，build()是最合理的位置。

内容的提问来源于stack exchange，提问作者haakym