单元测试的价值

以下是每当我提出将单元测试和代码覆盖作为开发周期不可分割的一部分的重要性时,我从经理/老板那里得到的一些典型答案(按落纱顺序排列)

"这是QA的工作,只关注功能和开发"

"应用程序不是关键任务,如果有一些错误,它不是世界末日"

"我们不能花时间进行单元测试"

"尽量不要过于花哨"

尽管做好了工作的最佳意图,但在责任游戏到来的那天结束时,负担最终落在了开发者身上.

我经常看到生产中断的事情,其中​​一些可以通过运行单元测试来静态捕获这些错误来避免.

我只想谈谈人们的经历是什么,以及解决这个问题的最佳方法是什么.

更新:感谢大家提供了许多富有洞察力的建议.有几个答案我希望我可以选择正确的答案.

将单元测试引入开发过程就像投资一样:你必须预先投入一些资金才能获得利润.如果你坚持下去,管理层应该更加关注这个比喻:描述需要什么样的投资,然后制定利润计划.

例如:投资:

花费时间来实施测试基础设施(如果没有特定于测试的基础设施代码,可以简化产品特定的测试模式,测试数据创建/删除等,则无法进行严格的产品单元测试);

花在编写实际测试上的时间;

花在审查和支持测试上的时间;

等等

利润:

没有标志就没有错误重新出现;

没有单元测试通过,不会发布主要功能;

循环开发-qa-fix错误减少了大部分错误:开发单元测试修复错误;

等等

大多数管理人员看不到单元测试的优势,直到他们在有意义的行动中看到它,所以我的建议,根据经验,采取ff步骤:

将单元测试应用于重复出现的错误 - 这是证明单元测试价值的最佳用例.如果你出现的错误只是出现并重新出现在其他所有版本中,那么单元测试将允许开发人员查看哪些更改导致了错误,除了事先提醒他们修复程序是有序的.向管理层展示也很容易.

将单元测试应用于常规错误 - 现在已经清楚地展示了单元测试的有用性,长期消失的多个重复漏洞的实例应足以鼓励每个人使用单元测试来评估所有错误,以防止它们成为重复出现的错误.

将单元测试应用于新功能 - 通过单元测试确保旧错误不会重现,并确认它们首先被修复,下一步是将其应用于新功能以确保最小化错误.明确表示不可能完全消除错误.

应用全面的TDD - 最后一步是在编码之前应用单元测试,作为一种设计工具,既有助于设计代码又可以最大限度地减少错误.

当然,我并不是说这很容易 - 我上面所说的是过于简单化,即使我每天都在努力 - 很难说服每个人.

如果您以后决定转到另一家公司,您可能希望明确寻找一家实施TDD的公司.

人们听他们的钱包.通过尽早捕获错误来显示可以节省多少时间.将其转化为美元储蓄.

关于#3,在单元测试上花费时间很可能会缩短整体上市时间.很棒的文章 - http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html

对我来说,采用单元测试的最大好处是我可以改变我的编码行为,使其更易于测试,换句话说,以更松散的耦合方式.

如果由于管理问题你不能在你的真实项目中练习单元测试,我会选择练习一些小玩具项目,只是为了强迫自己找到一种编写可测试代码的方法,即使没有单元测试.

我自己2美分.