如何说服项目发起人代码中的所有函数都应该进行单元测试[关闭]

Question

在大多数情况下，非技术人员认为编写单元测试没有任何价值。他们只想完成基本的代码，并不想花金钱和时间在单元测试之类的事情上。后来，他们每天都只是要求多修复一个错误。项目错过了最后期限，而且他们仍然看不到良好的自动化测试的价值。

Answer 1

最好的方法是不要对“非技术”人员过于技术化。只需将其纳入交货时间即可，无需详细说明。

另一方面，听起来项目的最后期限对于实际建造它来说并不现实。

Answer 2

我只是 写得很长 关于这个话题。

总结一下我针对常见投诉的论点：

清理工作对用户来说是不可见的；我们需要添加新功能。混乱的代码不断产生的错误对于用户来说也是可见的。花在修复这些错误上的时间本可以花在添加功能上。我们在质量债务中停留的时间越长，添加每个新功能所需的时间就越长。

我们没有时间打扫卫生。您宁愿花时间修复问题产生的错误而不是解决问题？这就像每个周末都在敲除杂草，而不是将它们连根拔起。预防比治疗更有价值十六倍。

开发人员让自己陷入了困境；他们应该在自己的时间里摆脱困境。如果开发人员没有像他们那样快速发布版本，如果他们没有对早期采用者的反馈做出如此迅速的反应，即使产品演变成与最初构想完全不同的野兽，我们也不会有现在的客户和收入。我们会为另一家公司工作，而不是抱怨我们构建的软件。

首席执行官注意：互相指责会阻碍解决问题。相反，挑战您的开发人员减少错误报告。这很容易测量，因此您可以跟踪时间与结果。请记住，开发人员更喜欢实现新功能而不是修复错误，因此如果他们乞求时间来修复错误，那就很严重了。

Answer 3

尝试使用模拟。询问他们是否希望自己的孩子驾驶沃尔沃或街上某个人制造的 Kit 汽车。答案应该永远是沃尔沃。然后问为什么？答案是它更可靠、更安全。他们怎么知道。答案是测试。所有汽车都经过极限测试，成本反映了这一点。如果他们希望软件尽可能可靠，他们就需要进行测试。（或者他们成为碰撞测试假人）

Answer 4

好吧，我认为问题是你说的是“所有功能”。所有功能都不需要单元测试，有些人会认为在许多情况下对单个功能进行单元测试是完全错误的。

相反，我建议对实际的“功能单元”进行单元测试。不要为每个功能编写一个测试，而是为每个场景或功能编写一个测试。除了节省大量时间并允许您在雷达下进行测试之外，它通常更加准确，因为它确实测试了它们正在使用的功能。通常，逐个功能的单元测试不能测试正确的东西，甚至更糟糕的是，测试模拟。

我建议您不惜一切代价避免在测试中使用模拟。使用模拟本质上会使测试无效，因为您正在测试它在理想环境中的工作原理，而不是它在现实世界中的工作原理。

另一个好处是您还可以获得更好的死代码检测。高级测试未涵盖的任何代码都可能未被使用并且可以被删除。永远不要低估消除死代码的价值。

Answer 5

开发已经开始后销售完整的单元测试是 非常 难的。我什至可以说这通常是不可能的。如果您没有得到所有项目利益相关者的支持，可以预先完成完整的单元测试，那么您应该对您可以参加的任何单元测试感到高兴。

Answer 6

你不知道。测试不应该是单独编写的，因此不需要在计划中考虑它们，就像您专门计划“编译”或“输入代码”一样。无论如何，编写测试所花费的时间都应该被它们节省的时间所抵消。

Answer 7

去做就对了。一开始你会比较慢，因为你要编写更多代码并首先思考问题。但你很快就会在项目上超越其他人，因为你的错误/缺陷更少，而且你的设计更好。

如果您在设计系统时考虑到了测试，那么它的设计本质上会比不可测试的设计更加灵活。以后添加功能会更快。

Answer 8

@Craig，我也考虑过汽车模拟，但我认为这个类比不成立，因为听起来该项目中已经存在测试，而这只是程度问题。在这种情况下，汽车类比就变成了“只要测试了关键系统（刹车、前灯、变速箱等），你就关心车内的顶灯是否得到测试吗”。作为一个忙碌的项目发起人，看到项目已经超过了结束日期，我并不真正关心顶灯是否经过测试。

Answer 9

推销单元测试价值的一个好方法是从支持的角度来看——如果您使用的单元测试框架具有可部署的运行时（nUnit 就是其中之一），则可以有一个“运行单元测试”菜单项在您的帮助菜单上。这可以运行所有单元测试，并且可以将结果发送给技术支持以帮助调试客户端问题。

显然，您可以通过多种方式来提高稳定性，但技术支持是大多数经理希望降低的“真金白银”成本。