什么时候单元测试不合适或不必要？ [重复]

#1 楼

在以下情况下，我个人不会编写单元测试：


代码没有分支是微不足道的。返回0的getter不需要进行测试，并且其使用者将通过测试来覆盖更改。
代码只需传递到稳定的API中即可。我以为标准库可以正常工作。
代码需要与其他已部署的系统进行交互。那么就需要进行集成测试。
如果成功/失败测试很难量化以至于无法可靠地测量，例如隐写术对于人类来说是不明显的。
如果测试本身比代码难编写一个数量级。
如果代码是一次性代码或占位符代码。如有疑问，请进行测试。

#2 楼

除非您不进行测试就编写代码，否则总是要承担测试成本。

进行单元测试与不进行单元测试的区别在于编写测试的成本之间的区别与手动测试相比。

如果编写单元测试的成本为2分钟，而运行单元测试的成本实际上为0，但是手动测试代码需要1分钟，然后如果您两次运行测试，您甚至会收支平衡。


多年以来，我一直误以为我没有足够的时间来编写代码我的代码的单元测试。当我确实编写测试时，它们是肿的，沉重的东西，这仅鼓励我认为我应该只在知道需要它们时才编写单元测试。

最近，我一直被鼓励使用Test驱动开发，我发现这是一个完整的启示。现在，我坚信我没有时间不编写单元测试。

根据我的经验，通过考虑测试进行开发，最终会得到更简洁的界面，更集中的类和模块和通常更多的可测试的SOLID代码。

每次我使用没有单元测试的旧代码，而我必须手动测试某些东西时，我一直在想：“如果该代码已经进行了单元测试”。每次我不得不尝试在具有较高耦合度的代码中添加单元测试功能时，我总是在想：“如果以非耦合方式编写，这将变得更加容易。”

比较和对比了我支持的两个实验站。一个已经存在了一段时间，并拥有大量的旧代码，而另一个则相对较新。

在向旧实验室添加功能时，通常是下手实验室并花费大量时间来研究其所需功能的含义以及如何在不影响任何其他功能的情况下添加该功能的情况。根本没有将代码设置为允许离线测试，因此几乎所有内容都必须在线开发。如果我确实尝试离线开发，那么最终我会得到比合理数量更多的模拟对象。

在较新的实验室中，通常可以通过在办公桌旁离线开发功能来添加功能，仅模拟那些需要立即执行的操作，然后仅在实验室中花费很短的时间，以解决所有未脱机处理的剩余问题。


TL; DR版本：

写测试的时间和编写测试的费用加上所需运行次数的成本相比，可能会比手动测试次数高

请记住，如果您使用TDD，编写测试的成本可能会随着性能的提高而降低，并且除非代码绝对琐碎，否则您可能最终会运行测试次数超出您的预期。

#3 楼

就我个人而言，我通常不为以下内容编写单元测试：


更改现有的非单元测试（旧版）代码。从理论上讲开始单元测试永远不会太晚，但实际上，将单元测试添加到从未进行过TDD的代码中所获得的收益很小。唯一的好处是可以防止回归。您可以查看更改对您可能会或可能不会影响的区域产生的影响。但是，单元测试只能证明代码仍然可以像编写测试时那样工作。因为测试不是基于原始要求编写的，所以该测试不能证明当前的实现是“正确的”。在我的经验中，对这样的代码库进行单元测试的更改甚至是噩梦，然后再进行更改并手动执行程序的受影响区域。您首先必须为有问题的代码编写适当的单元测试（这可能需要重构代码以允许模拟和其他对TDD友好的体系结构），证明它已通过并且重构没有破坏任何内容（当这是第一个针对百万LoC代码库编写的单元测试，这可能很困难），然后更改测试以期望有所不同，然后更改代码以使更改的测试通过。
UI布局和顶级行为。在某些情况下，这是不可行的。许多带有“设计者”的IDE都将UI元素声明为私有的，从概念上讲，它们不应公开。使它们内部化将需要将单元测试与生产代码置于同一程序集（错误），并使它们受到保护将需要“测试代理”，该代理公开了我们需要了解的控件知识（通常也不是其完成方式）。即使可以公开所有控件并因此可以访问它们的类型，位置，格式属性等，验证UI的测试还是非常脆弱的。通常，您仍可以在codebehinds / viewmodels中对事件处理程序进行单元测试，然后证明单击按钮会触发处理程序很简单。
数据库持久性。根据定义，这是一个集成测试。在处理将数据传递到存储库的代码时，您总是会模拟存储库，而在存储库本身中进行开发时，则会模拟ORM的挂钩。虽然有“数据库单元测试”，并且您可以使用SQLite之类的“模拟”数据库，但我发现这些测试永远无法适合单元级别。
第三方代码。您可以按自己的意愿测试代码，并相信所使用的第三方工具的开发人员（包括.NET Framework本身的组件，例如WPF，WCF，EF等）的工作正确无误，直到证明错误为止。证明您进行了正确的WCF调用的单元测试不需要实际越过服务代理，并且没有必要测试特定的WCF服务调用在单元测试中是否正常工作（是否起作用取决于特定于环境的变量）在本地测试环境中可能是完美的选择，但在构建机器人或QA，Staging或UAT环境中则不是最佳选择；这是更高级别的集成，AAT和手动测试仍然有价值的地方。

在几乎所有其他情况下，测试优先方法在执行需求和YAGNI，防止回归，识别需求冲突等方面都具有重要价值。即使在“琐碎”代码的情况下，验证“是的，此属性仍会返回此”。价值，因此您可以相信在其他测试中”对于开发人员来说对我来说是有价值的。

#4 楼

在编写单元测试的成本和它们增加的价值之间需要权衡。忽略此风险可能会导致过度测试。

blueberryfields提到了一个会影响单元测试价值的变量：项目的稳定性（或开发进度）。我想在此基础上进行扩展。

进行单元测试的价值大致遵循以下图表（是的，MS Paint！）：





在第一个区域中，代码不稳定到经常需要重写或完全废弃单元测试的地步。这可能是您不会使用的原型。或者它可能是您不熟悉编程语言或框架（并且经常需要重做大量代码）的项目。

单元测试非常适合在模块级别进行重构（即更改职能）。问题是，当代码在体系结构级别不稳定时，可能会重写，删除或完全重新设计整个模块。然后必须更改/删除/添加单元测试，这是一个负担。

在此阶段，限于系统级集成测试，甚至手动测试是一种更好的方法（您再次选择该方法）取决于编写测试的成本与获得的值）。

单元测试在第二个区域中增加了最大的价值，在该区域中，代码在模块级别之上变得稳定，但尚未达到模块级别。如果您有稳定的代码库，并且要添加一个很可能留下的模块，那么这就是单元测试大获胜的时候。

当稳定性很好时，单元测试的价值也开始降低。被测代码的数量很高。测试标准库函数的简单包装器就是单元测试过大的一个例子。

如果您正在编写的一段代码可能永远都不需要更改，并且您确信它已经做到了对（也许这很简单？），测试的价值较小。


当效用大于成本时，单元测试将变得有益，如下图II区所示。



对于不同的成本，此成本线可能处于不同的水平人（第1行与第2行）。如果您不熟悉项目中使用的测试框架，则可以提高水平，并减少网络实用程序。较高的成本（第2行）缩小了适用于单元测试的范围。

成本线不一定必须保持不变。特别是当您考虑其他变量（例如项目规模）以及该项目是否已经存在测试框架时，情况可能就是如此。

#5 楼

单元测试最有价值的地方在哪里？


您应该只为逻辑代码编写单元测试。逻辑代码的定义如下：

逻辑代码是其中包含某种逻辑的任何代码，
可能很小。如果它具有以下一项或多项内容，则它是逻辑代码：IF语句，循环，开关或case语句，
计算或任何其他类型的决策代码。


如果那是单元测试最有价值的领域的尽头，
那另一端是什么？



紧密耦合的代码无法轻松测试。有时根本无法测试。例如，ASP.NET Web表单是一场噩梦，有时甚至无法测试，这与考虑到单元测试的ASP.NET MVC相反。
我可能选择不为非常小的和简单的项目编写测试。在时间和资源有限的情况下，这是完全合理的。是的，这是有风险的，但是当您工作的公司上市时间有限时，这是完全可以接受的。


什么情况下您都不会打扰？
维护测试的努力在哪里不值得花费？具有高代码覆盖率的单元测试为您提供了一种宝贵的信心，使您对系统的行为充满信心。集成测试也是如此，但这不是您的问题。

我的回答基于以下假设：


您知道单元，集成和集成之间的区别。功能测试。
您精通其中一个单元测试框架，并且编写单元测试的工作量很小。
编写单元测试时，您不会觉得自己在做额外的工作。

参考：单元测试的艺术

#6 楼

肯特·贝克（Kent Beck）（单元测试的概念背后的人）说，在可能会扔掉的想法（例如原型）上工作时，如果不决定继续工作，最好不要编写单元测试。相反，如果您编写原型并决定继续使用它，则由于先前答案中提到的所有原因，单元测试将非常有用。

#7 楼

您确实应该对打算多次运行的任何代码进行测试。

如果打算运行一次然后将其丢弃，则测试可能没有用，尽管如果域是复杂的情况下，我还是应该编写测试来帮助我进行设计和实现。

否则，即使测试所做的唯一事情就是确认您的假设仍然正确，但它们是有价值的。持续时间超过单个会话的任何代码都需要进行修改，这时测试将为自己支付10倍以上的费用。

#8 楼

我对不必要的内容毫无头绪，但是当我认为单元测试不合适时，我会去争取，因为它们会增加成本而没有成比例的收益：

如果我们的组织/开发团队未进行任何单元测试，然后，除非您能够说服其他开发人员运行，修复（并自行创建）单元测试，否则将不会运行和维护您创建的测试。 （这意味着您正在与其他人一起开发软件。）

并非每个人都在进行单元测试，它们有时会受到本地团队文化的支持，而在这种环境下，您首先需要在实际开始编写单元测试之前，对大多数开发人员以及可能在构建过程（“ [连续]集成”）中使用它们，都是有意义的。

考虑到时间压力和交付日期和“您”在团队中的相对地位-编写单元测试有意义的剩余时间很容易就可能是数月或数年。

#9 楼

有时您没有时间进行单元测试。没关系。

存在外部约束，并且您可能不会在给定的时间内感到需要进行测试，因为您可能认为自己对整个系统状态有了牢固的了解，并且知道更改将如何波动。

，但我仍然相信您对此应该感到内。
所以当事情开始崩溃时，您会知道这是因为：“哦，是的，我没有测试东西，让我们开始测试。“

在那一刻之前，内的感觉将帮助您避免某些体系结构的选择，这些选择会阻止您稍后再执行代码测试。

#10 楼

代价不是维护测试，而是维护工作代码。如果您离婚了测试和实施，则假定您编写的内容将在没有证据的情况下起作用。测试为您提供了证明，并为您提供了随着时间的流逝维护代码的信心。当然，您可能会认为您永远不会再访问曾经认为是一掷千金的应用程序，但是事实是，您花费任何时间编写软件都是您的雇主不希望轻视的投资。面对现实吧，软件开发人员通常并不便宜，花在代码上的时间只是浪费了雇主的钱。

如果您遇到问题，请写几行代码看看某个东西是如何工作的，或者简单地为Programmers.SE编写一个示例，那么这是创建满足您对问题的了解后完全打算扔掉的东西的情况。在这种情况下，单元测试可能会阻碍任务执行，并可以安全地排除在外。但是，在所有其他情况下，即使程序看起来相对不重要，我仍然认为测试始终是适当的，并且您应始终以编写具有足够测试支持的专业标准为目标，以减少维护代码的难度。未来。

#11 楼

在一个项目中要进行的单元测试的数量和质量与开发速度和产品所需的稳定性直接成正比。

一方面，对于一次性脚本，简单的演示，或者在非常早期的快速启动环境中，单元测试不太可能对任何事情都有意义或有用。几乎可以肯定，它们几乎总是在浪费时间和资源。

另一方面，编写控制起搏器或飞行员的软件时，或者在保持稳定，高度的工作时复杂的软件系统（例如，跨多领域广泛采用的编译器），多层单元测试和其他覆盖范围至关重要。

[还有许多其他特定于情境的因素，每个因素都起着重要作用。方式或其他方式，例如您的团队规模，预算，开发人员的才能，您首选的软件开发策略等。通常，在最高抽象层次上，我发现这两者之间的差异最大]

#12 楼

在我看来，产品/代码原型不需要测试，因为它们通常是使用与成品完全不同的过程和完全不同的目的交付的。

想象一下这种常见情况。您拥有某种以公司闻名的技术，您的销售团队或首席执行官会去找客户，并向他们出售可以利用您的技术的其他产品。他们在那里出售产品，然后向客户保证他们将在一个月内看到Beta版本。您什么都没有，甚至没有开发团队。

接下来发生的事情是，您根据同意/卖给客户的观点快速设计解决方案，组建了一个（通常是明星）工程师团队，并开始编写代码。当然，如果您的约会不拖延（他们总是这样做）并且您设法在三周而不是四周的时间内编写代码，那将是理想的选择。在这种情况下，您有一个额外的星期，如果您能够确保质量检查小组在本周的时间，您将对其进行测试。实际上，您没有多余的一周时间，并且/或者您的质量检查团队还需要另外两个月的时间来支持其他产品的交付。此外，您没有任何设计规格，因此质量检查团队不会知道他们应该测试什么。因此，您最终要通过一些自己的冒烟测试来交付编写的内容，而这并不是真正的测试，仅仅是因为您没有资格测试自己的代码。这里最大的因素是，客户端将很快看到一些承诺的功能。如果您的原型能够完成任务，那么您将回到绘图板，在此处设计并计划实际的1.0版-这次是正确的。

就单元测试而言，它们很好地维护了某些合同（我保证我的代码会这样做，如果没有的话，它会被破坏）。在进行原型制作时，您可能并不需要太在意合同，因为无论是因为客户端消失了，还是因为最终使用不同的技术/工具开发了1.0版，您的原型通常都无法成为1.0版。这里的一个例子是一个快速的原型网站，一个人用一个月的时间就用PHP很快地编写了一个快速的原型网站，然后您组成一个团队用JEE重写它。即使数据库也常常无法幸免于此更改。

#13 楼

当维护，扩展或传达应用程序逻辑而没有缺陷的逻辑理解能力超出（或将来可能超过）团队中知识最少的成员满足该理解能力时，您应该编写单元测试。 br />
基本上取决于您一次可以保持多少脑子。您可能会更加自信，可以编码（完全了解更改的影响），直到达到一定的复杂度为止。在此之前，单元测试会分散注意力，阻碍您前进。在团队中，阈值将更低，因此您非常需要立即进行单元测试来抵消小组的愚蠢。如果您从其他人那里接过一个未经测试的项目（或者您早就忘记了一个项目），则在更改任何内容之前，您都希望编写单元测试，因为您的理解将为零。

注意：编写更少的代码并练习YAGNI，可以降低复杂度，从而减少所需的单元测试数量。

#14 楼

单元测试固然很好，但在具有许多“活动部件”的复杂系统中，它们实际上并没有进行太多测试。

众所周知，单元测试可确保给定输入X为单元，则得到输出Y，其中X是所有适当的输入，而Y是所有适当的输出。但是，我发现大多数代码都能完成开发人员认为应该的工作。.但实际上却没有必要。
（您可能会认为它像枪一样。枪具有一堆精密零件，这些零件是分开制造的，然后组装。如果枪在实际射击时会爆炸，则是否对每个特定零件的功能进行了良好的测试都没关系。免责声明：我对火器武器一无所知（：）

在这种情况下，我们需要在模型生产环境中进行实际的系统测试。由于无论如何都在这里测试功能，因此单元测试的价值会有所降低。

但是，在这种情况下，单元测试仍然很有价值，因为它们可以确保功能实际上，您希望保持不变的确会保持不变，这非常有价值，因为它使您对需要进行重点测试的系统区域充满信心。

#15 楼

IMO单元测试在任何代码库中都是不合适的（不是不必要的！），因为它需要大量的重构时间甚至需要彻底重写才能引入单元测试，因为在这段时间内分配给管理层非常困难。 。

#16 楼

在一个快速发展的小型组织中，我发现开发人员承受着巨大的压力以保持生产力和快速发展，以至于他们常常根本不愿意去测试自己的变更。

我们有一条总体政策规定：如果您进行更改（无论是错误修复还是增强功能），则开发人员应在提交代码进行进一步质量检查之前对其进行测试。

对于大多数实例，我们实际上并不编写单元测试因为我们的屏幕主要是通过以下方式设计的：如果在屏幕上进行了更改，则必须遍历其余逻辑，以便找出更改是否成功。

我发现开发人员必须进行自己的测试，无论是否进行了记录，因为他们最了解逻辑中的潜在弱点在哪里。

所以我想说，即使您没有为系统的每个小部分编写单元测试，也应该进行常识测试。