单元测试多少钱是件好事？

Question

(没有"相关问题"似乎指出这一点,所以这里.)

我正在研究生产代码.争论用户不可见的任何事情有时很难做到.如果销售人员无法看到它,那么这对他们来说是一个外部成本,他们会反对它,除非有充分的理由不这样做.

单元测试多少钱是件好事？如果您测试每个类,每个方法,您当前的版本将花费更长时间,可能更长.如果您没有进行任何测试,将来的维护将花费更长的时间,可能会更长,因为错误修正和新功能会导致您无法预见的问题,并且单元测试会被捕获.

你如何找到一个健康,合理的平衡？

编辑:回答人们合理提出的几个问题......

1. 销售没有运行过程,但它们肯定有输入,并且应该在任何组中输入有限.他们是支付账单的人.如果他们完全转向一切,那显然是不合理的.

2. 我确定没有最好的答案,但我很好奇其他人认为合理的.我期待两个极端(一切!没有!),中间有很多.

3. 没有人会选择他们的经理,如果在单元测试一个糟糕的政策是在与公司/项目的人住一个化妆成败的决定......你有很多更多的职业选择比大多数人来说,朋友.:-)

第二编辑:"正当"是一个重要的词.如果我希望有时间预算/允许进行单元测试,并且不想隐藏它,我将需要证明其原因.对我来说,现在最重要的答案是"之前已经破解的测试事物",因为我总能证明反应政策的合理性.

关于如何为积极主动的事情辩护的任何想法？

Answer 1

最小单元测试的两个建议将提供最大的"降压":

首先分析您的应用程序以找到最常用的部件 - 确保这些部件经过单元测试.继续向外移动到不太常用的代码.

修复错误后,编写一个可以检测到错误的单元测试.

Answer 2

我认为这是一个谬误:

如果您测试每个类,每个方法,您当前的版本将花费更长时间,可能更长.

测试 - 特别是测试优先 - 改善我们的流量,让我们保持在区域内,实际上加速了我们.我工作得更快,因为我测试了.它未能通过测试减慢了我们的速度.

我不测试getter和setter; 我认为这是毫无意义的 - 特别是因为它们是自动生成的.但几乎所有其他东西 - 这是我的做法和我的建议.

Answer 3

给我的建议是这样的:

• 试试你的意思; 过了一会儿,评估自己:
• 如果测试花费的时间超过您认为合理的时间,并且您的投资回报率太低,那么测试的次数就会减少.
• 如果您的产品经过足够的测试而且您已经浪费了时间,那么请进
• 根据需要循环.

另一种算法:-)

• 有些测试非常简单,而且非常有用.始终以高优先级执行此操作.
• 有些测试很难设置,很少有用(例如,它可能会在您的过程中经常发生的人工测试中重复).停止这样做,它正在浪费你的时间.
• 在两者之间,尝试找到一个平衡点,根据项目的各个阶段,可能会随着时间的推移而变化.

更新了评论,关于证明一些测试的有用性(你坚信的那些):

我经常告诉年轻的同事,我们技术人员(开发人员等)缺乏与管理层的沟通.正如您所说,对于管理层而言,未列出的成本并不存在,因此他们避免使用这些成本无法证明其他成本是合理的.我曾经也对此感到沮丧.但想一想,这就是他们工作的本质.如果他们在没有正当理由的情况下接受不必要的成

这并不是说我们认为这些活动是有用的,这些活动都是对的.但我们首先必须明确成本.更重要的是,如果我们以适当的方式报告成本,管理层将不得不做出我们想要的决定(或者他们将是糟糕的经理;请注意,决策仍可能优先考虑......).所以我建议跟踪成本,以便它们不再隐藏:

• 在您跟踪花费时间的位置,请单独记下未经测试的代码所产生的成本(如果在工具中不可用,请将其添加为注释)
• 如果工具没有在专用报告上汇总这些费用,那么每周,您的经理会读到您花费的时间的X%
• 每次评估负载时,分别评估几个选项,无论是否进行自动化测试,都表明手动测试或自动测试的时间大致相同(如果您将自己限制在最有用的测试中,如前所述),而后者是一种抵御回归的资产.
• 将错误链接到原始代码.如果链接不在您的进程中,请找到连接它们的方法:您需要显示该错误来自没有自动测试.
• 还收集这些链接的报告.

为了真正影响经理,您可以每周向他们发送最新的电子表格(但包含整个历史记录,不仅仅是本周).SpreadSheet提供了立即理解的图形,让不信的经理得到原始数字......

Answer 4

开始为最有问题的区域创建单元测试(即经常断开并导致销售团队和开发人员之间进行大量通信的代码段).这将导致销售团队和其他人员立即产生明显的影响.

然后,一旦你有可信度并且他们看到了价值,就开始添加较少问题的区域,直到你开始注意到ROI不再存在.

确实完全覆盖在理论上是好的,但在实践中通常没有必要.更不用说太贵了.