API Platform PUT/PATCH接口PHPUnit测试失效问题咨询

1. 为何PUT/PATCH在实际使用中正常但PHPUnit测试失效？如何解决？ #

核心原因 #

内置测试页与PHPUnit测试的请求数据处理逻辑存在差异：

• 内置测试页发送的是部分修改字段的JSON数据，API Platform会先通过Provider加载原始实体转为DTO，再将请求体的字段合并到该DTO上，最终交给Processor保存修改。
• 你的PHPUnit测试是直接将修改后的DTO对象序列化后发送，但API Platform仍会执行Provider加载原始DTO，此时若你的DTO序列化时未携带所有必要字段（或序列化组配置不全），请求体中的数据无法完全覆盖原始DTO的字段，导致最终保存的还是数据库原数据。

解决方法 #

• 调整测试请求构造方式：不要直接序列化DTO对象，而是构造包含修改字段的数组并转为JSON发送。示例代码：

  // 原错误测试方式
  $dto = $this->getComponentDtoFromEntity($entity);
  $dto->setName('New Name');
  $this->client->request('PUT', '/api/components/'.$entity->getId(), [
      'json' => $this->serializer->serialize($dto, 'json')
  ]);
  
  // 修正后的测试方式
  $this->client->request('PUT', '/api/components/'.$entity->getId(), [
      'json' => [
          'name' => 'New Name',
          // 其他需要修改的字段
      ]
  ]);
  

• 完善DTO序列化组配置：确保PUT/PATCH操作使用的序列化组包含所有可修改字段，避免请求体遗漏字段导致原始值被保留。示例ComponentDto配置：

  #[ApiResource(
      operations: [
          new Put(
              normalizationContext: ['groups' => ['component:read']],
              denormalizationContext: ['groups' => ['component:update']]
          )
      ]
  )]
  class ComponentDto
  {
      #[Groups(['component:read', 'component:update'])]
      public string $name;
      // 其他字段的Groups配置
  }
  

• 禁用Provider（按需）：若你的场景不需要基于原始实体修改，可显式设置provider: null跳过原始资源加载，同时在Processor中直接处理请求体的DTO：

  #[ApiResource(
      operations: [
          new Put(
              processor: ComponentUpdateProcessor::class,
              provider: null,
              skip_exists: true // 跳过资源存在性校验
          )
      ]
  )]
  

2. 为何仅指定Processor时，PUT/PATCH仍会调用Provider？ #

API Platform对PUT/PATCH这类针对现有资源的更新操作有默认行为：

• 这类操作默认需要验证资源存在性、支持并发控制（如ETag）、以及处理部分字段更新的合并逻辑，因此必须加载原始资源。
• 即使你未显式指定Provider，API Platform会自动使用默认的Doctrine Provider（如果你的DTO与Doctrine实体关联）来加载对应实体并转为DTO。

只有当你明确不需要加载原始资源时（比如用PUT创建新资源），才可以通过provider: null禁用Provider调用，但此时需要自行在Processor中处理资源的查找或创建逻辑，同时配置skip_exists: true跳过默认的存在性校验。

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