Symfony单元测试开箱即用但需理解配置：PHPUnit预装且自动加载tests/目录；KernelTestCase用于服务测试，WebTestCase用于HTTP测试；数据库隔离需显式选择事务或截断策略；自定义工具类须符合PSR-4命名规范。

Symfony 的单元测试集成非常友好，开箱即用，但“友好”不等于“无脑”，关键在于是否理解它默认集成的 PHPUnit 配置、测试目录结构和 KernelTestCase / WebTestCase 的职责边界。

PHPUnit 已预装且配置就绪

Symfony 项目初始化后，phpunit.xml.dist（或 phpunit.xml）已存在，自动加载 vendor/autoload.php，并默认扫描 tests/ 目录。不需要手动安装 PHPUnit 或写 bootstrap —— 只要运行 ./vendor/bin/phpunit 就能跑通空测试。

• 默认使用 SYMFONY_PHPUNIT_VERSION 环境变量控制 PHPUnit 版本，避免全局版本冲突
• tests/bootstrap.php 自动注册 Symfony 的 autoloader 和设置 $_SERVER['APP_ENV'] = 'test'
• 若修改了 composer.json 中的 autoload-dev，需确保 tests/ 被包含，否则类找不到

KernelTestCase 和 WebTestCase 不是万能胶

这两个基类提供容器和 HTTP 测试能力，但容易误用：前者只启动 kernel（适合测试 service、repository），后者才启动完整 HTTP stack（适合 controller、路由、表单）。混用会导致测试变慢或行为异常。

Json Schema Toolkit

使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。

下载

• 用 KernelTestCase 测试 controller 会跳过路由匹配、中间件、事件监听器等 —— 实际请求流程被绕过了
• 用 WebTestCase 测试一个纯 DTO 或 validator 类，属于大炮打蚊子，启动 kernel 开销不必要
• static::createClient() 返回的 client 默认不启用 profiler；如需断言性能或事件，得手动启用：

  static::createClient(['debug' => true])

测试数据库隔离靠 DatabaseTransactionTrait 或 DatabaseTruncationTrait

Symfony 不自动清库。官方推荐的 doctrine/doctrine-fixtures-bundle 仅用于加载 fixture，不解决并发测试污染问题。

• DatabaseTransactionTrait 在每个 test method 前后开/回滚事务 —— 快，但不支持 DDL（如 CREATE TABLE）或跨连接操作
• DatabaseTruncationTrait（来自 doctrine/doctrine-test-bundle）真正 truncate 表，兼容所有 SQL，但更慢，需显式配置 default_connection
• 别在 setUp() 里手动 $em->flush() + $em->clear() —— 这不能保证事务隔离，尤其当测试并行运行时

自定义测试工具类要小心 autoloading

比如你写了 tests/Support/TestUserFactory.php，想在多个测试中复用用户创建逻辑。它不会被自动加载，除非：

• 该文件放在 tests/ 下且命名空间为 AppTests*（与 composer.json 中 "autoload-dev": {"psr-4": {"App\Tests\": "tests/"} 匹配）
• 或直接 require_once，但破坏可维护性
• 若用 symfony/flex 生成的项目，tests/ 默认走 PSR-4，但注意文件名必须匹配类名（TestUserFactory.php → class TestUserFactory）

最常被忽略的是测试环境配置的加载顺序：.env.test 会覆盖 .env，但 config/packages/test/*.yaml 才是最终生效的配置源 —— 比如你关掉某 bundle 的 profiler，得在这里配，而不是改 .env.test。