如果项目具有100%的单元测试覆盖率,是否仍需要集成测试？

如果项目具有100%的单元测试覆盖率,是否仍需要集成测试？

我从未参与过具有100%单元测试覆盖率的项目,但我想知道你的项目是否获得了这个(或90%),你的体验是否还需要集成测试？(你需要更少吗？)

我问,因为集成测试似乎很糟糕.它们通常是缓慢的,脆弱的(容易折断),不透明(当有人不得不潜入所有层以找出问题时),并且导致我们的项目放慢速度......我开始认为拥有只有单元测试(也许是一小部分烟雾测试)才是最佳选择.

从长远来看,似乎集成测试(根据我的经验)比他们节省的成本更高.

谢谢你的考虑.

我认为在讨论之前定义你的术语很重要.

单元测试单独测试单个单元.对我来说,那是一堂课.单元测试将创建一个对象,调用方法并检查结果.它回答了"我的代码是否符合我的意图？"的问题.

集成测试测试系统中两个组件的组合.它侧重于组件之间的关系,而不是组件本身.它回答了"将这些组件按预期一起工作"的问题.

系统测试测试整个软件系统.它回答了"这个软件是否按预期工作？"的问题.

验收测试是一种自动化的方式,让客户回答"这个软件我认为我想要的是什么？".这是一种系统测试.

请注意,这些测试都没有回答诸如"这个软件有用吗？"之类的问题.或"这个软件易于使用吗？".

所有自动化测试都受到公理的限制" 端到端比你想象的更远 " - 最终人类不得不坐在电脑前看着你的用户界面.

单元测试更快,更容易编写,运行更快,更容易诊断.它们不依赖于"外部"元素,如文件系统或数据库,因此它们更简单/更快/更可靠.大多数单元测试在重构时继续工作(良好的单元测试是安全重构的唯一方法).他们绝对要求你的代码解耦,这很难,除非你先写测试.这些因素的组合使得TDD的Red/Green/Refactor序列运行良好.

系统测试很难编写,因为它们必须经过如此多的设置才能达到您想要测试的特定情况.它们很脆弱,因为之前软件行为的任何变化都会影响导致您要测试的情况的顺序,即使该行为与测试无关.出于类似的原因,它们比单元测试慢得多.故障可能非常难以诊断,因为它可能需要很长时间才能到达故障点,并且因为故障涉及太多软件.在某些软件中,系统测试很难自动化.

集成测试介于两者之间:它们比系统测试更容易编写,运行和诊断,但覆盖范围比单元测试更广.

使用测试策略的组合来平衡每个的成本和价值.

是.

即使所有"单位"都做他们应该做的事情,也不能保证整个系统按设计工作.