如果单元测试是如此伟大，为什么更多的公司不去做呢？

Question

我工作的第一个真正的软件公司是关于单元测试(NUnit)的。我不知道那时候我们真的很执着--我不知道我们的代码覆盖率是怎样的，我在编写大部分的单元测试。从那时起，我遇到了一些公司做了大量的测试，但它的椅子测试:依赖于一个人在那里，有较低的重复性和机会捕获错误。另一种态度是:这是他们想要“在未来”进行的事情，基本上是当金钱从天而降的时候。

我错过了单元测试--这只会让生活更轻松。但我发现，当我寻找一份新工作时，单元测试要么是公司希望在未来“着手”的东西，要么是他们根本不做的事情(嗯，它已经存在了一段时间了！)我想说的是，在过去的两年中，我看过的60%-75%的工作需求根本没有列出单元测试。我只能想到一两个有单元测试经验的人(对于中级开发人员来说)。

所以问题是，，少了什么？我认为它能让人们更有效率，但那只是在花了大量的时间去做之后。关于单元测试的成本节约，难道没有任何好的研究吗？是我要找的那种公司吗？

编辑:尽管标题有点邪恶的倡导者，我认为自己是一个单元测试的支持者。

Answer 1

根据我的经验，这其中涉及几个因素：

1. 管理层并不真正理解单元测试到底是什么，也不明白为什么它对他们有真正的内在价值。
2. 管理层倾向于更多地关注产品的快速交付，并且(错误地)认为单元测试与该目标适得其反。
3. 有一种误解认为，测试完全属于QA的普遍存在。开发人员是程序员，不能编写测试。
4. 有一种普遍的误解是，尽管工具是免费的，但管理层必须花钱才能正确地进行单元测试。(当然，开发人员有更多的时间考虑，但这并不是真的让人望而却步。)
5. will的答案将结束这个答案:很难确定测试代码的值(编辑jcollum)

当然，还有其他因素，但这正是我到目前为止遇到的情况。

Answer 2

1)这很难

2)这需要时间

3)很难确定测试代码的值

第三点是粘稠的。好的单元测试可以减少bug。但是好的生产代码也是如此。如何确定由于单元测试而不存在多少bug？你无法衡量什么是不存在的。你可以指出你的研究，但它们不适合你的业务经理的电子表格。

Answer 3

把所有的责任都归咎于“管理”是很容易的。但是管理层真的告诉你不要做任何单元测试吗？

管理通常不会(也可能不应该)告诉您如何完成您的工作，无论是模块化、抽象数据类型、设计模式还是单元测试。这些是一个成功的、有能力的软件工程师应用的交易工具，但是一个糟糕的工程师却没有。

我认为你的问题的真正答案是:单元测试是非常困难的，而计算机科学专业的学生没有接受过这方面的培训。

在编写自己的字符串类时，这很容易。当您测试一个真实的产品时，您会遇到在powerpoint幻灯片中没有人告诉您的挑战：

• 用户交互。应用程序的一半是用户界面逻辑。如何以自动化的方式测试它，如果你移动一个按钮，它不会崩溃？
• 与外部API和框架的交互。如果您正在编写Windows内核驱动程序，如何对其进行单元测试？您是否为您使用的每个IRP和内核函数编写存根，从而有效地创建操作系统内核的模拟？
• 网络通信是21世纪的事情。如何协调由几个分布式组件组成的单元测试？
• 如何选择好的测试用例？我经常看到人们尝试“在1000次迭代的循环中做一些随机的事情，看看它是否会中断”。当您这样做时，所付出的努力要高于回报，错过了重要的bug，并且放弃了单元测试。
• 如何测试性能要求是否满足？
• 测试中的模式知识很少:存根、罐装响应、回归测试是大多数人不知道的概念。在你工作的地方，有多少人读过一本关于单元测试的书？

我们可以归咎于管理层的一点是，需求规范很少包含任何关于可交付产品质量级别的需求。

下次当你的老板要求你做时间估计时，包括写单元测试的时间，看看会发生什么。