如果单元测试是如此出色，为什么没有更多的公司这样做呢？[关闭]

我工作过的第一家真正的软件公司就是单元测试（NUnit）。我不知道那时我们是真正的坚持者-我不知道我们的代码覆盖率是什么样，我正在编写大多数单元测试。从那时起，我遇到了一些公司进行大量测试的公司，但它是椅子测试：依赖于那里的人，可重复性低，发现错误的机会也很小。另一种态度是：这是他们希望“将来”发展的东西；基本上是从天上掉下来的钱。

我想念单元测试-它只会使生活更轻松。但是我发现，当我寻找一份新工作时，单元测试要么是公司将来希望“跟上去”的事情，要么就是根本不做的事情（嗯，它已经存在了一段时间了）现在！）。我想说，过去两年来我查看的60-75％的工作要求根本没有列出单元测试。我只能想到有一个或两个具有单元测试经验的要求（对于中级开发人员职位）。

所以问题是，缺少了什么？我认为这可以使人们提高生产力，但这只是在花费大量时间实际进行之后。关于单元测试的成本节省，没有好的研究吗？这是我正在寻找的公司类型吗？

编辑：尽管标题有点像恶魔拥护者，但我认为自己是单元测试的支持者。

以我的经验，这涉及两个因素：

1. 管理层并不真正了解单元测试的真正含义，也不知道为什么它对他们具有真正的内在价值。
2. 管理层倾向于更加关注产品的快速交付，并且（错误地）将单元测试视为不利于该目标。
3. 有一种误解，认为测试完全属于质量检查的范畴。开发人员是编码人员，无法编写测试。
4. 尽管工具是免费提供的，但人们普遍误以为管理层必须花钱进行正确的单元测试。（当然，开发人员会增加时间来考虑，但这并不是禁止的。）
5. Will的答案将使该答案更加全面：很难确定测试代码的值（编辑jcollum）

自然地，还有其他因素，但这只是我到目前为止遇到的问题。

1）很难
2）需要时间
3）很难确定测试代码的值

点3是粘性的。好的单元测试可以减少错误。但是好的生产代码也是如此。您如何确定由于单元测试而导致的错误数量不存在？您无法衡量不存在的内容。您可以指向研究，但它们并不适合您的业务经理的电子表格。

将所有责任归咎于“管理”很容易。但是管理层是否真的在告诉您明确不进行任何单元测试？

无论是模块化，抽象数据类型，设计模式还是单元测试，管理人员通常不会（也可能不会）告诉您如何完成工作。这些是成功的，胜任的软件工程师可以应用的交易工具，而贫穷的工程师则不能。

我认为对您的问题的真正答案是：单元测试确实很困难，并且计算机科学专业的学生也没有为此接受过培训。

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

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

我们可以归咎于管理的一件事是，需求规范很少包含对交付成果质量水平的任何要求。

下次老板要求您进行时间估计时，请包括编写单元测试的时间并查看会发生什么情况。

大多数测试不测试任何东西。
您编写了一个fileopen（）函数和一个单元测试，如果该文件不存在，则该单元测试将失败，如果该文件存在，则该单元测试将成功。大！现在您是否检查了它是否适用于BIG5中文文件名？在NFS共享上？在Vista上，USB闪存盘上的文件已打开并且UAC已打开？

问题在于，单元测试是由编写函数的同一位程序员编写的，具有相同的假设条件和相同的技能水平。为了真正发挥作用，测试必须由其他人编写，只能按照已发布的规范进行，而无需他们查看代码。-在大多数公司中，仅获得书面规格将是一个突破！

单元测试检查单个功能代码中的错误。它们可以用于数据访问层，数学库等，其中输入/输出是众所周知的，并且内部结构很复杂，但是在很多情况下，这只是浪费时间。
当错误是由于代码的不同部分之间或与操作系统以及用户之间的交互而导致时，它们将失败。高/低DPI设置使对话框混乱或外语设置交换“。”之类的问题。和'，'通常找不到。

已经对单元测试的ROI进行了研究-请参阅此问题。

我发现了很多对单元测试不感兴趣的开发人员。当您开始时，似乎总是需要付出很少的努力。没有人愿意报名参加额外的工作，因此他们拒绝。一旦人们开始，他们通常会热情地坚持下去，但是让他们开始可能很难。

除了采用单元测试的问题外，单元测试并不总是值得的，尽管总的来说，我认为正确应用单元测试是值得的。单元测试没有什么特别之处，可以使它们免于遭受不良结构的攻击。

单元测试具有成本（创建，维护和运行），并且只有在提供比这些成本更大的收益时才值得。测试创建是一项与其他技能一样的技能，它需要获得成功的特定经验和知识。没有足够的经验，即使没有经验的开发人员也很容易创建不值得的低质量，低价值和/或高成本的单元测试。尤其是考虑到判断单元测试的价值有多困难。

另外，单元测试只是提高代码质量的一种方法，但不是唯一的方法。在某些情况下和某些团队中，这可能不是提高软件质量的最有效方法。

请记住，在单元测试中投入大量精力并不能保证高质量的软件。而且，无需进行任何单元测试就可以生产最高质量的软件。

好吧，我的公司还没有采用TDD或单元测试。老实说，我们不确定该怎么做。我们显然可以对像CapitalizeString（）之类的愚蠢函数执行此操作，但是我们不知道如何对具有复杂对象的高度复杂的系统执行此操作。而且，大多数受访者要么零经验，要么经验有限。从SO人群看来，单元测试很大，但在可用工作池中并不是特别重要。

TDD是一个单独的主题。我们在道义上反对TDD。我们不是牛仔编码员，但我们确实相信它会阻碍项目的创造力和灵活性。而且，让编写单元测试功能的编码器没有意义。当我做某事时，我会编码所有我能想到的边缘情况。我需要的是另一个大脑来寻找我可能错过的事物。我们没有那个。团队很小，设备齐全。

简而言之，我们不相信TDD，但是我们想进行单元测试。我们只是没有经验，所以我们很难找到它。

有很多公司实际上没有按照最佳做法做任何事情。没有代码审查，没有单元测试，没有测试计划，什么都没有，只是坐在他们的裤子旁边。

以此为契机，让他们使用持续集成平台并开发单元测试！一种简单的方式来打动原有功能并同时提高代码的质量和稳定性

编辑：作为理由，我认为他们只是不知道使CI和单元测试变得异常容易的当前工具。

我认为懒惰不是不良单元测试的根本原因。对于我的公司而言，时间限制和“做到即刻完成”的态度是进行单元测试的最大威慑力。同样，我们系统失败的地方往往更多地是在集成级别（服务，数据库访问，需要特定数据进行测试的复杂查询），而不是“单元级别”。这些事情很难进行测试，如果您几乎没有足够的时间完成功能，则可能没有时间同时进行任何有用的测试。

就像编译器一样，单元测试应该只是代码开发工作流的自然组成部分。

但是，这需要对管理人员进行单元测试的好处方面的教育。但是，初级开发人员具有这种影响的机会相对较低。因此，公司是否支持单元测试取决于公司是否拥有提倡单元测试的高级开发人员或架构师。

我相信这是对您的问题“缺少什么以及为什么没有更多公司进行单元测试”的答案。:-)

它可能是您已经提到的几件事的组合。它很难衡量TDD节省的成本。如果您想将IT外包，则可以显示您每年为有薪员工支付的费用以及外包费用。它非常具体。您怎么说：“哦，此测试捕获了一个错误，该错误需要我4个小时来调试和修复...”？

一些地方不使用它的原因仅仅是因为开始和继续需要大量的工作。对于一些管理人员来说，编写单元测试所花的时间与编写实际功能所花的时间差不多，就像您将开发人员的工作效率降低了一半一样。

最重要的是，您需要建立团队（或其他人）来构建基础架构并进行维护。

正如艾伦（Alan）所说，许多地方根本就没有采用最佳做法-他们只是想看到有形的东西。

据我所知，许多公司都有庞大的，高度耦合的代码库，这些代码库几乎不能进行单元测试。它们也没有可测试的要求，因此单元测试将针对“按实际情况构建”的实际要求进行测试。

我认为程序员必须开始这样做。作为开发的一部分，很容易就可以进行一些简单的测试。

为了快速进行调试，几乎总是需要诸如单元测试之类的东西。只需说明启动测试比安排正确的输入，设置调试器断点，启动应用程序等要快得多。

用您的代码记录测试。只需发表评论，说明测试在哪里以及如何运行。未来的程序员会看到它，并希望测试能够传播！

单元测试是大多数人都听说过的黑匣子术语之一，但不知道什么真正构成了单元测试，从哪里开始，如何编写它们，如何实际运行测试，应该精确地测试什么，等等。等等等等

在许多情况下，不确定的开发人员更容易将其简单地视为不必要的或只是“企业级开发人员”需要的糖衣而忽略掉。

我是单元测试的忠实拥护者，并且我还是一家公司的合伙人，该公司为各种客户类型进行合同开发项目。在一个月内，我们将涉及3-4个不同规模的不同项目。

如果一个项目看起来像是一个项目，那么我就不会在单元测试上投入大量资金，因为该单元测试无法为我的业务带来回报。在这些类型的项目中，我将对不确定，不熟悉或可能经常更改的事物进行单元测试（例如，我无法控制的数据源的解析器）。

而如果我要构建的东西我知道会使用很长的时间，那是一项更大的工作，那么我将通过多次迭代来进行工作，如果发生错误，它将对我的客户产生很大的影响，我将投资进行更多的单元测试。再次，测试的优先级围绕不确定/不熟悉/更改的代码。

我认为单元测试应该围绕任务的复杂性以及它们是否有回报。编写多余的代码是没有用的。

以我的经验，这实际上取决于您正在编写的软件。我发现为UI编写单元测试非常困难。我仅对系统中具有明确输入/输出的部分使用单元测试。

我想念单元测试-它只会使生活更轻松。

确实，这不是公司采用单元测试的充分理由。

一个充分的原因可能是“更便宜”（和/或“更好”）：这很难证明单元测试。

唯一的好理由可能是“编写单元测试是开发人员时间的最佳利用”，这确实很难证明IMO：在某些地方，对于某些软件，对于某些开发人员，这可能是正确的，而在其他地方却不正确。

有很多开发人员不认为单元测试的世界：包括一些认为其他形式的测试（例如自动集成/功能测试）可能更便宜，更有价值的开发人员，例如，我是唯一一个不这样做的开发人员吗？喜欢单元测试吗？

当然，在理想的世界中，您不能反对进行单元测试。

但是，是否编写单元测试取决于许多因素：

• 如何使用该软件。如果您只是为自己编写软件，您会编写单元测试吗？可能不是。如果您要编写预包装的软件以进行商业销售，可能是的。

• 有多少人维护该代码。...如果只是您，那么您可能会足够了解它，因此可以在进行更改后快速确定代码的运行速度足以确保没有任何问题。如果其他最初不是编写代码的人现在必须维护它，那么单元测试将使他们充满信心，当他们更新代码以修复较大的代码（显然没有在单元测试中捕获！）时，他们没有破坏任何东西。 。

• 代码复杂度：仅需要测试的测试代码。单行变量分配方法不需要测试。具有多个执行路径的50行方法可能会执行。

• 商业上的实际考虑：编写单元测试所花的时间比不进行的时间长。如果您正在编写具有不确定商业前景的原型软件，那么在快速拥有代码与现在的效果（与在两周内进行单元测试的代码效果更好）之间有一个收获。有时需要快速找出（消费者的胃口）软件是否会像货架一样短并进入下一个项目。

而且正如其他人指出的那样，测试仅与编写它的人一样好。

主要原因是许多开发人员和开发经理都不知道存在单元测试或如何使用它们的线索。

第二个原因是单元测试只能（以明智的方式）与已经满足某些质量标准的代码一起使用。有可能某些现有代码库不属于该类别。

第三个原因是懒惰和/或便宜。

因为单元测试仅在编写可测试的代码时才有用。而且编写可测试的代码很困难。人们是懒惰的和/或便宜的。

编辑：细微的“懒惰”为“懒惰和/或便宜”；在极少数情况下，人们实际上拥有技能和能力并且愿意编写测试，但是他们还有其他事情要做，而这些事情会更直接影响底线。

我认为部分问题是开发人员期望业务人员具有相同的价值观，并真正关心“我们是否应该进行单元测试？”的答案。我们不会事先获得企业的批准使用高级语言而不是汇编语言-通常这是完成工作的明智方法。

关键是，我们是唯一有资格进行通话的人（这并不是说我们所有人对该主题都具有相同的知识）。此外，即使您的团队在政策上不进行单元测试（或您每天的方法名称），这通常也不表示您不能这样做。

事实是，我们不能在粒度上证明我们所做的大多数事情的投资回报率。为什么单元测试符合这种不合理/非典型的证明标准，这超出了我的理解范围...

人们很懒惰，只有在被迫改变时才会采取改变。

我的2美分：

• 它需要一定的教育和纪律，但是新毕业生已经具备了适当的知识。
• 使用更好的工具可以减少测试开销，而且这种情况也在发生（重构等）。

因此，这只是时间问题。

在马丁·科普林（Martin-Coplien）辩论中，鲍勃·马丁（Bob Martin）断言：

“如今，对于开发人员来说，交付未在单元测试中执行的代码行是不负责任的。”

[ http://www.infoq.com/interviews/coplien-martin-tdd]

如果您想卖给所有人进行测试，请执行以下操作：

1. 编写一堆测试。
2. 通知其他更改代码并通过测试的开发人员。
3. 他们将修复其代码。
4. 现在，您可以发布而无需那些特定的错误。

即使是经理也可以理解这一点。

公司之所以没有执行单元测试，是因为许多网站的撰写质量不佳（无知和人们遵循旧习惯）。在我公司，自从我们开始使用Nunit和Typemock进行单元测试以来，我们获得了更高的代码覆盖率，并在较短的时间内发布了该软件。

像大多数好的创意一样，采用创意与组织路径依赖关系更大，而与创意质量无关。

在大多数已交付产品的公司中，已经建立了实质性的质量检查部门，并设有高级质量检查主管。测试是质量检查小组的信条。

质量检查团队不太可能编写单元测试代码，因为该公司通常不会为质量检查团队配备重型编码人员。

编程团队不愿编写测试代码，因为它与QA团队产生了冲突。

在没有将QA分解成单独的工作职能的小组中，我一直看到了更多的兴趣和对单元测试的采用

很简单，编写和更新单元测试要花钱。大多数公司以前的软件都没有单元测试，因此编写成本会很高。因此，他们不会这样做，这会增加开发过程的时间，因此也不会将其添加到新功能中。

大多数公司都没有用。显然，不是您（或我）工作的那个人。