本文介绍一种简洁可靠的 phpunit 测试方案：通过注入 monolog 的 `testhandler` 收集所有日志，再使用 `hasinfothatcontains()` 等断言方法检查是否至少有一条日志包含预期关键词，从而验证 facade 方法是否正确触发了多路径逻辑（如发送多类邮件并记录对应日志）。
在单元测试中验证“多个日志消息中至少存在一个匹配项”，不应依赖对 MockObject 的多重 expects() 设置——因为 PHPUnit 的 mock 期望是按调用顺序和次数严格匹配的，而日志写入是异步、多次、无序发生的，直接为同一方法（如 info()）设置多个独立 expects() 会导致冲突（正如你遇到的错误：后置期望被前置调用覆盖，断言失败）。
更健壮、更符合测试意图的做法是：不 mock 日志器，而是注入一个真实可收集日志的测试专用 logger。Monolog 官方提供的 \Monolog\Handler\TestHandler 正是为此设计——它不输出日志，只将所有记录暂存于内存，供断言时灵活查询。
✅ 推荐实现方式（基于 Monolog TestHandler）
首先确保项目已安装 Monolog（通常 Laravel/Symfony 项目已自带）：
composer require --dev monolog/monolog
然后在测试中按如下方式使用：
立即学习“PHP免费学习笔记（深入）”；
use Monolog\Logger;
use Monolog\Handler\TestHandler;
public function testSendEMailsLogsAtLeastOneExpectedMessage(): void
{
// 1. 创建测试专用 logger + TestHandler
$testHandler = new TestHandler();
$logger = new Logger('mailing-test');
$logger->pushHandler($testHandler);
// 2. 注入到被测 facade（需支持构造函数或 setter 注入）
$this->facade->setLogger($logger); // 或通过构造函数传入
// 3. 执行被测行为
$reportDto = new ReportDto('test-report');
$this->facade->sendEMails($reportDto);
// 4. 断言：检查日志中是否 *至少存在一条* 匹配任一关键词的 info 级别消息
$this->assertTrue(
$testHandler->hasInfoThatContains('Owner mail sent to') ||
$testHandler->hasInfoThatContains('Pno mail sent to') ||
$testHandler->hasInfoThatContains('Group mail sent to'),
'Expected at least one of the email-sent log messages was missing'
);
}? 补充断言能力（提升可读性与精度）
TestHandler 还提供多种实用方法，可根据需要组合使用：
| 方法 | 说明 |
|---|---|
| hasInfoThatContains(string $substring) | 检查是否存在 info() 级别且消息含指定子串的日志 |
| hasWarningThatContains(), hasErrorThatContains() | 同理，适用于其他日志级别 |
| getRecords() | 获取全部日志记录数组（含 level、message、context、channel 等），支持自定义遍历断言 |
| hasRecord(string $message, int $level = Logger::INFO) | 精确匹配完整消息（注意：含动态内容如邮箱、ID 时慎用） |
例如，若需验证「所有三类邮件日志均出现」，可改用：
$this->assertTrue($testHandler->hasInfoThatContains('Owner mail sent to'));
$this->assertTrue($testHandler->hasInfoThatContains('Pno mail sent to'));
$this->assertTrue($testHandler->hasInfoThatContains('Group mail sent to'));⚠️ 注意事项
- 避免 mock LoggerInterface 做多期望：这是根本性误区。mock 适合验证“是否以特定参数调用了某方法”，而非“是否发生了某业务结果”；日志是副作用，应通过可观测的收集器验证。
- 确保日志器注入生效：确认 MailingFacade 的 setLogger() 方法正确替换了内部 logger 实例，或优先使用构造函数注入（更易测试）。
- 处理动态内容：日志中常含邮箱、ID、时间戳等动态值（如你报错中的 <a class="__cf_email__">[email protected]</a>），务必使用 contains() 类断言，而非全等匹配。
- 复用优化：可将 TestHandler 和 Logger 封装为 PHPUnit Trait（如 LogTestTrait），在多个测试类中统一初始化 $this->testHandler 和 $this->logger，提升可维护性。
通过该方案，你不再纠结于 mock 的调用时序，而是聚焦于业务结果的可观测证据——日志作为关键副作用，成为验证 facade 是否成功驱动下游组件的可靠信标。
