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

解决方案

回答

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

回答

在开发已经开始后，出售完整的单元测试非常困难。我什至可以说这通常是不可能的。如果我们没有从所有项目涉众那里买到钱来进行完整的单元测试，那么我们应该为可以加入的任何单元测试感到高兴。

回答

最好的方法是不要让"非技术"人员变得如此技术。只需将其构建为交货时间即可，而无需关注细节。

另一方面，听起来项目的截止日期实际上并不现实。

回答

@Craig，我也考虑过汽车模拟，但是我认为这个比喻会崩溃，因为听起来项目中已经存在测试，这只是程度的问题。在那种情况下，汽车比喻为"只要测试关键系统(刹车，前大灯，变速箱等)，我们是否关心汽车的顶灯是否受到测试"。作为一个饱经风霜的项目发起人，他们看到该项目已经超过了结束日期，所以我并不在乎是否需要对圆顶灯进行测试。

回答

你不知道测试不应该是分开编写的，因此，与在计划"编译"或者"键入代码"中专门安排的时间相比，在计划中无需考虑它们。无论如何，花费在编写测试上的任何时间都应抵消它们为我们节省的时间。

回答

从支持的角度来看，出售单元测试价值的一种好方法是-如果我们使用的单元测试框架具有可以部署的运行时(nUnit是一个)，则可以在菜单项上找到"运行单元测试"菜单帮助菜单。这可以运行所有单元测试，并将结果发送给技术支持以帮助调试客户端问题。

显然，有很多方法可以出售提高的稳定性，但是技术支持是大多数经理想要降低的"真钱"成本。

回答

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

相反，我建议对实际的"功能单元"进行单元测试。不必为每个功能编写单个测试，而为每个场景或者功能编写测试。除了可以节省大量时间并允许我们在雷达下进行测试外，它通常更加准确，因为它可以从字面上测试其使用方式的功能。按功能进行单元测试经常无法测试正确的东西，甚至更糟糕的是无法测试模拟。

我建议我们不惜一切代价避免在测试中使用模拟。使用模拟实际上会使测试无效，因为我们正在测试理想状态下的工作方式，而不是实际环境中的工作方式。

附带的好处是我们还可以获得更好的死代码检测。任何高级测试未涵盖的代码都可能未被使用，可以将其删除。永远不要低估消除无效代码的价值。

回答

我只是详细写了这个话题。

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

清理对用户是不可见的；我们需要添加新功能。
用户也可以看到由凌乱的代码不断产生的错误。花在修复这些错误上的时间本可以花在添加功能上。我们呆在质量欠债上的时间越长，添加每个新功能所花费的时间就越多。

我们没有时间清理。
我们宁愿花时间修复由问题产生的错误，而不是解决问题？就像每个周末都在hack杂草，而不是将其扎根。预防的价值是治疗的十六倍。

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

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

回答

去做就对了。开始时，我们会变得很慢，因为我们要编写更多的代码并首先考虑问题。但是，由于错误/错误更少，并且设计更好，因此我们将很快在项目中传递其他人。

如果我们在设计系统时就考虑了测试，那么与非测试相比，设计在本质上将更加灵活。这样，将来便可以更快地添加功能。