如果您(或您的组织)希望彻底进行单元测试,那么如何衡量您的努力的成功或质量呢?
- 您是否使用代码覆盖率,您的目标百分比是多少?
- 您是否认为像TDD这样的哲学比度量更具影响力?
如果您(或您的组织)希望彻底进行单元测试,那么如何衡量您的努力的成功或质量呢?
我的建议并不是用来判断你是否有良好的单元测试,而是一种逐步构建出良好测试套件的方法。
每当你遇到一个bug,无论是在开发过程中还是由他人报告,都要进行两次修复。首先创建一个可以重现问题的单元测试,当你得到失败的测试结果时,再去解决问题。
如果问题一开始就存在,它就暗示着代码或领域的细微之处。添加一个测试可以确保它将来永远不会再次出现。
这种方法的另一个有趣的方面是,在实际查看代码的复杂性之前,它将帮助你从更高的层次理解问题。
此外,其他人提到的测试覆盖率的价值和陷阱也值得关注。
代码覆盖率是一个有用的指标,但需要谨慎使用。有些人过于关注代码覆盖率,特别是被覆盖的百分比,并认为它是衡量好的单元测试的主要指标。
我的经验告诉我,比起试图获得 100% 的覆盖率(这并不容易),人们应该专注于检查是否覆盖了关键部分。但即使这样,你可能也会得到错误的结果。
我非常支持TDD,但是我并不太重视测试覆盖率统计数据。对我来说,单元测试的成功和实用性体现在开发团队在开发周期中感受到的几个方面:(a)及早发现错误,(b)使重构和更改不会引入回归问题,(c)帮助完善模块化、解耦的设计,(d)等等。
或者,就像Martin Fowler所说,支持单元测试和TDD的轶事式证据是压倒性的,但你不能衡量生产力。请在他的博客上阅读更多内容:http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
如果它能够破坏,那么它应该被测试。如果它可以被测试,那么它应该被自动化。
代码覆盖率对于测试而言就像测试对于编程一样重要。它只能告诉你是否存在问题,但无法告诉你什么时候一切都正常运行。应该达到100%的代码覆盖率或者更高。代码逻辑的分支应该使用多个输入值进行测试,全面检查正常情况、边缘情况和特殊情况。
我通常进行测试驱动开发,因此我首先编写测试案例,这有助于我看到如何使用对象。
然后,在编写类时,大部分时间我可以发现常见的陷阱(例如,我做出的假设,例如变量是特定类型或特定值范围),当这些情况出现时,我会为该特定情况编写一个具体的测试案例。
除此之外,尽可能覆盖代码(有时无法达到100%),你也基本完成了。然后,如果未来出现任何错误,只需确保首先编写一个暴露它的测试案例,并在修复后通过测试即可。 然后按照正常流程进行修复。
除非您开发的是关键任务软件,否则不要期望达到100%的代码覆盖率。达到这一水平的成本非常高,并且对大多数项目来说不值得这样做。
监控代码覆盖率是有用的,但是与其专注于任意目标率(80%、90%、100%?),我发现把目光放在随着时间推移而呈现出积极趋势上更为实用。