我们通过测试金字塔知道应该有比端到端测试更多的单元测试。
但问题是如何获得正确的比例？
如果我们有49％的端到端测试和51％的单元测试吗？
我正在考虑使用codeception和phpunit测试的web应用程序api端点。
或者我们应该针对10％的端到端测试和90％的单元测试。
根据这些百分比，我的意思是如果我们用端到端测试覆盖x％，那么不要用单元测试覆盖相同的代码。
但是我错了，也许我们需要用单元测试覆盖相同的行，即使它们被端到端测试覆盖，正如Martin Fowler在这里写道：
https://martinfowler.com/bliki/TestPyramid.html
我一直认为高级别测试是作为第二行的 测试防御。如果你在高水平测试中失败，那不仅仅是做到了 您的功能代码中有错误，您也缺少或 不正确的单元测试因此我建议在修复暴露的bug之前 在高级别测试中，您应该使用单元测试来复制错误。然后 单元测试确保bug保持死亡状态。
如果端到端测试涵盖相同的代码以保存开发时间，我们通常不会在单元测试中使用相同的代码。
但是如果我们需要用单元测试来覆盖相同的代码，那么这意味着我们应该尽可能少地覆盖端到端，但至少要对API端点进行一次基本调用，因为无论如何它应该由单元测试覆盖。 / p>
答案 0 :(得分：0)
即使测试覆盖相同的代码，测试也有不同的用途。它们之间的比例并没有特别的意义。
单元测试涵盖各个功能单元;端到端测试涵盖逻辑流程。单元测试告诉您隔离的代码片段按预期运行;流测试告诉你代码作为一个应用程序一起运行。
你应该致力于最大化两者的覆盖率。目标是让单元测试覆盖所有代码，并使流程测试覆盖所有流程（应该是绝大多数代码）。
真的，它完全依赖于你的应用程序。根据经验，我预计单元测试至少比流量测试高出一个数量级（10倍）。两者都应接近100％的代码库覆盖率。但就像我说的那样，我认为这不是一个有意义的指标。
答案 1 :(得分：0)
如果我要设定目标 - 它的比例为100：1。但当然项目是不同的，项目的阶段也很重要。
我的经验法则是 - 如果可以通过单元测试覆盖逻辑 - 它应该用单元测试来覆盖。这就是我与Martin Fowler不同意的地方，因为如果你能用单元测试覆盖逻辑 - 你为什么还要费心去编写系统测试呢？
要确定要编写哪个测试，可以将它们分为两类：
这种逻辑可以将高级测试的数量保持在最低水平。所以现在如果编写了系统测试，那么因为你无法编写单元测试而编写它。
但除了单元和系统（e2e）测试之外，还有一些东西 - 组件（a.k.a集成）测试。他们初始化了应用程序的一大部分（这使得它们不是单位），但并不要求整个应用程序运行（这使得它们不是系统）。许多检查都可以通过这种方式完成，并且比系统测试更快（更快），更可靠。
您可以在this article中了解如何在实践中应用此逻辑。
答案 2 :(得分：0)
我个人并不在乎这个比例。我什至可以拥有比单元/集成测试更多的E2E测试。
我主要使用React开发Web应用程序：
getFilteredItems 这种划分确保了我不会陷入一个经过良好测试但无法正常工作的项目的怪异感觉，此GIF中对此进行了完美总结。而且它可以防止在不同级别多次测试相同的代码，从而提高了可维护性。
最后，回答您的问题：我当前项目的比率应该为10/30/60。
