Automation 测量API的测试覆盖率

鉴于自动化测试的重要性，我想知道是否有可能测量Pact测试的测试覆盖率

请记住，对于单元测试，大多数框架/IDE提供了检查代码的哪些部分被执行的方法，从而检查代码的至少每个部分（比如在类中）是否被某个测试执行

相应地，Pact测试（旨在检查提供者或消费者是否符合API规范）通过测试大多数可能的交互来获得可信度。如果确实如此，那么它可以通过将e2e测试的逻辑划分为功能部分来减少e2e测试的数量，功能部分包括一个组件内的单元和集成测试，以及断言两个组件符合约定API的pact测试。（有关详细信息，请参阅。）

考虑到可以通过库（如Enounceate或swagger）自动发现某些web组件的REST API，我想知道是否可以将它们的发现与PACT测试描述进行比较，以查看后者是否缺少任何重要参数或端点。（另外，我不确定这是否意味着要加倍努力来提供明确的注释和契约，但在我看来，Java中的明确注释并没有那么重，也就是说，主要是通过REST注释来识别REST端点，这对于功能来说是必要的。）

---

如果我的问题对于stackoverflow来说过于笼统，请告诉我，我更愿意在更多的学术网站（如stackexchange）上提问。

来自docs.pact.io问题档案：

如何判断我的API是否具有良好的契约测试覆盖率？ 这实际上是一个错误的问题。合同测试并不打算提供任何特定百分比的提供者覆盖率（这是提供者自己的功能测试的目的）。契约测试旨在提供（尽可能接近）100%的消费者代码覆盖率，以调用提供者（您可以将其视为“提供者客户端代码”）。如果在测试套件中的单独步骤中执行消费者Pact测试，则可以使用标准代码覆盖率工具确定Pact测试是否覆盖了提供商客户机代码的足够百分比

这并不能告诉您是否涵盖了参数的所有不同变化。要确保对每个参数变化都进行契约测试通常是不完全可行的（想象一下必须尝试并覆盖特定枚举的20个不同组合）。在那个阶段，加入一些精心挑选的测试用例，然后确保您的代码能够优雅地处理任何异常（例如，进行良好的监控，将意外值报告给开发团队），这可能是一个更有效的选择。

谢谢。好主意（尤其是链接中的细节）。TLDR关于供应商的问题是错误的，因为他需要提供多份合同。对于消费者来说，在运行PACT测试时，可以使用标准的测试覆盖率工具进行测试。