你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
Conformance tests 究竟证明什么？
检查实现是否遵守声明的公共契约，而非只检查示例能跑。
- 实际 Provider输入已知资源→
- 共享测试 + Fixture比较行为与契约→
- 可检查的结果
把承诺变成可执行检查
AFS 的 runProviderTests() 接收 provider 工厂、资源结构和相应操作的 fixture，让多个实现接受共同的检查。结构描述告诉测试有哪些节点；能力声明决定哪些额外行为需要被验证。
例如声明支持条件写入，就需要相应的 ifMatch fixture，而不是仅在文档里写一句“支持并发”。相关测试还要求指向同一底层存储的独立 provider 对象，避免只验证单个对象内部的锁。
// Fixture outline: fill in a real provider and its actual structure.
runProviderTests({
name: "ReportProvider",
createProvider: () => new ReportProvider(),
structure: { root: { name: "", children: [
{ name: "report", content: { title: "Prepare the keynote", status: "draft" } }
] } }
});通过不等于无条件保证
测试证明的是给定版本、fixture 和环境中的契约。它不自动证明真实外部服务可用、跨进程并发正确、权限配置正确或业务流程完整。
好的 fixture 应接到真实实现，不应该用专为测试编写的假返回值代替实际 provider。新增能力时，要同步扩展被检查的行为。
示例中的三个词
Provider 工厂是“每次调用都创建一个 provider 实例”的函数，即示例里的 () => new ReportProvider()。Fixture 是测试准备的数据与约定，例如有哪些资源、读取后应得到什么内容。测试用这些已知输入和预期结果检查实现。
上面的最小结构示例只建立资源与读取的检查基础，没有提供条件写入的测试数据，也不能证明写入或并发正确。条件写入指“资源版本仍符合我给出的条件时才允许写入”；声明这种能力后，要额外提供 ifMatch fixture，包括指向同一底层数据的另一个 provider 实例。跨进程保证还需要相应的跨进程测试。