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

最好的办法是不要和“非技术性”的人接触。只需在交付时间内构建它,而不必详细说明。

从另一方面来说,项目的最后期限似乎并不现实。

我只是 wrote at length 关于这个话题。

总结我反对常见投诉的观点:

清理对用户是不可见的;我们需要添加新功能。 用户也可以看到由混乱代码不断产生的错误。修复这些错误所花费的时间本来可以用来添加特性。我们在高质量债务中停留的时间越长,添加每个新功能所需的时间就越多。

我们没有时间清理。 你宁愿花时间去修正问题产生的错误,而不是修正问题?这就像每个周末都要除草,而不是把它们连根拔起。预防是治疗的16倍。

开发人员把他们自己弄得一团糟;他们应该在自己的时间里把自己从混乱中解脱出来。 如果开发人员没有像他们那样快速地发布产品,如果他们没有对早期采用者反馈做出如此迅速的响应,即使产品变成了一个与最初概念完全不同的野兽,我们也不会有我们当前的客户和收入。我们将为另一家公司工作,而不是抱怨我们开发的软件。

注意首席执行官的:指尖妨碍解决。相反,挑战您的开发人员减少错误报告。这很容易测量,所以您可以跟踪时间和结果。记住,开发人员更喜欢实现新的特性而不是修复bug,所以如果他们需要时间来修复bug,这是很严重的。

尝试使用模拟。问他们是否愿意让他们的孩子开Volvos或是街上某个男人制造的工具车。答案应该总是沃尔沃。然后问为什么?它更可靠,更安全。他们怎么知道的?答案是测试。所有的汽车都经过了极端的测试,其成本与此相关。如果他们希望软件尽可能可靠,他们需要测试。(或者他们变成了碰撞试验的假人)

我认为问题是你说的是“所有功能”。所有的函数都不需要单元测试,一些人认为单元测试在许多场景中都是错误的。

相反,我建议使用单元测试实际的“功能单元”。不是为每个函数编写一个测试,而是为每个场景或特性编写一个测试。除了为你节省大量的时间,让你在雷达下进行测试之外,它通常更准确,因为它确实测试了它们使用的功能。函数单元测试常常不能测试正确的东西,甚至更糟的是,测试模拟。

我建议您无论如何都不要在测试中使用模拟。模拟的使用本质上使测试无效,因为您正在测试它在理想化环境中的工作方式,而不是在现实世界中的工作方式。

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

在开发开始后销售完整的单元测试是 非常 很难。我甚至会说这通常是不可能的。如果您没有从所有项目涉众那里获得预先完成单元测试的认可,那么您应该为您可以参与的任何单元测试感到高兴。

您不应该这样做。测试不应该是单独编写的,因此在计划中不需要比专门计划“编译”或“键入代码”更多地考虑它们。编写测试所花费的任何时间都应该被它们为您节省的时间所抵消。

想做就做。当你写更多的代码并且首先考虑问题的时候,你在开始的时候会慢一些。但是你会很快地把其他人传给项目,因为你的错误/错误更少,你的设计也更好。

如果您在设计系统时考虑了测试,那么设计本身就比不可测试的设计更灵活。在将来,向中添加功能将更快。

@克雷格,我也考虑过汽车模拟,但我认为这个类比是不成立的,因为听起来项目中已经有了测试,这只是一个程度问题。在这种情况下,汽车的类比变成“你关心的是,只要测试了关键系统(刹车、前照灯、变速器等),汽车的顶灯是否被测试了”。作为一个苦恼的项目发起人,看到项目已经过了它的结束日期,我真的不在乎穹顶灯是否得到测试。

从支持的角度来看,出售单元测试价值的一个好方法是——如果您使用的单元测试框架具有可以部署的运行时(nunit是一个),那么您可以在帮助菜单上有一个“运行单元测试”菜单项。这可以运行所有的单元测试,结果可以发送到技术支持以帮助调试客户机问题。

很明显,有很多方法可以用来销售稳定性增强的产品,但技术支持是一种“真正的金钱”成本,大多数经理都希望降低成本。