PHP面向对象编程的深入理解：测试与 mocking 的完整实战指南

1. 1.1 PHP 面向对象编程的核心概念

1.1.1 面向对象的基本要素

面向对象编程（OOP）在 PHP 中的核心要素包括类、对象、属性与方法、以及访问控制（public、protected、private）的作用域管理。掌握这些元素是实现高内聚、低耦合设计的基础，也是后续单元测试与 mocking 的前提。

类是对象的模板，实例化后成为对象，具备状态（属性）和行为（方法）。在设计阶段应优先考虑职责单一、抽象清晰、接口明确的类边界，以便替换实现时保持行为一致性。

1.1.2 封装、继承与多态

封装通过访问修饰符和内部实现屏蔽细节，提供稳定的外部接口，有助于在测试中聚焦公共行为而非内部实现。

继承与多态允许子类复用父类逻辑并在需要时替换实现，在测试中应通过依赖注入接口来解耦，以便对具体实现进行替换或模拟，从而提高测试灵活性。

2. 2. 测试驱动开发与策略在 OOP 中的作用

2.1 测试在对象设计中的角色

测试驱动的设计鼓励在实现前先定义接口和行为契约，这有助于把系统拆分成可独立验证的单元，并通过替换实现来验证复杂交互。

在面向对象设计中，测试强调对公共 API 的覆盖，而非私有实现细节。这也推动了对依赖关系的明确管理与更好的错思路分离。

3. 3. PHPUnit 环境搭建与快速入门

3.1 安装与配置

PHPUnit 是 PHP 领域最常用的单元测试框架，通过 Composer 进行开发依赖管理可以确保版本稳定性与复现性。

建议在项目中添加 phpunit.xml 或 phpunit.xml.dist，以统一测试配置、测试目录以及覆盖率选项，从而实现可重复的测试执行。

{
  "require-dev": {
    "phpunit/phpunit": "^9.5"
  }
}

4. 4. PHPUnit 的 mocking 实战

4.1 使用 Mock 对象解耦依赖

mocking（模拟对象）是单元测试的关键技巧，它让外部依赖不再真实执行，而是通过预设的行为来驱动测试。通过它可以验证系统在不同依赖状态下的行为是否符合预期。

使用 PHPUnit 的 createMock、getMockForAbstractClass 以及 expect/will 组合，可以对依赖的接口进行细粒度断言，从而实现对业务逻辑的稳定验证。

repo = $repo;
    $this->mailer = $mailer;
  }
  public function register(string $email, string $password): bool {
    if ($this->repo->exists($email)) {
      return false;
    }
    $user = ['email' => $email, 'password' => password_hash($password, PASSWORD_DEFAULT)];
    $this->repo->save($user);
    $this->mailer->sendWelcome($email);
    return true;
  }
}
?> 

5. 5. 设计可测试的 PHP OOP 架构

5.1 依赖注入与接口化设计

通过构造函数注入依赖并对外暴露接口类型，可以在测试时替换实现而不改动业务代码，这是一种实现解耦的有效实践。

接口化设计有助于定义契约，确保不同实现之间的行为一致，从而提升代码的可测试性与可维护性。

repo = $repo;
    $this->emailService = $emailService;
  }
  public function register(string $email, string $password): bool {
    if ($this->repo->findByEmail($email)) {
      return false;
    }
    $this->repo->save(['email' => $email, 'password' => password_hash($password, PASSWORD_DEFAULT)]);
    $this->emailService->send($email, '欢迎注册', '感谢您的加入');
    return true;
  }
}
?> 

6. 6. 实战案例：用户注册流程的测试与 mocking

6.1 场景描述

在真实应用中，用户注册涉及数据持久化、邮件通知等外部行为，通过 mocking 可以对这些行为进行独立验证，确保核心业务逻辑在不同情景下的正确性。

该案例聚焦在“重复注册防护”和“成功注册后触发通知”两条关键路径，并演示如何用接口解耦、如何断言外部行为的执行情况。

6.2 测试实现细节

通过创建用户仓储的 Mock 和邮件服务的 Mock，我们可以验证注册流程是否遵循正确的流程顺序与条件分支，而无需实际连接数据库或发送邮件。

createMock(UserRepositoryInterface::class);
    $mailer = $this->createMock(EmailServiceInterface::class);

    $repo->method('findByEmail')->willReturn(null);
    $repo->expects($this->once())->method('save')->with($this->arrayHasKey('email'));
    $mailer->expects($this->once())->method('send')
           ->with($this->anything(), $this->anything(), $this->anything());

    $service = new UserService($repo, $mailer);
    $this->assertTrue($service->register('new@example.com', 'secret'));
  }

  public function testRegisterRejectedIfEmailExists() {
    $repo = $this->createMock(UserRepositoryInterface::class);
    $mailer = $this->createMock(EmailServiceInterface::class);

    $repo->method('findByEmail')->willReturn(['email' => 'exists@example.com']);
    $repo->expects($this->never())->method('save');
    $mailer->expects($this->never())->method('send');

    $service = new UserService($repo, $mailer);
    $this->assertFalse($service->register('exists@example.com', 'secret'));
  }
}
?> 

7. 7. 高级话题：静态方法与最终类的测试挑战

7.1 静态方法的替代方案与测试策略

静态方法在测试中往往带来耦合与切换困难，推荐使用依赖注入的包装器或服务定位器来替代直接静态调用，以便于对外部行为进行替换与断言。

最终类与私有构造等设计会影响 mocking 的能力，应通过引入接口、工厂模式或包装层来保持测试的可控性与可替换性。

mailer = $mailer;
  }
  public function sendWelcome(string $email): bool {
    return $this->mailer->send($email, '欢迎', '感谢注册');
  }
}
?> 

8. 8. 常见误区与实战要点

8.1 测试粒度与覆盖率的权衡

过度测试对内部实现细节进行断言会降低维护性，应更关注公共行为和对外契约。

不应把所有逻辑都写成小而碎的单元测试，需结合集成测试来验证模块间的真实协作，以确保系统在真实场景下的可靠性。