我的问题假设人们已经相信某种单元测试是值得的，并且实际上是在他们当前的项目上写下来的。我们还假设代码的某些部分的单元测试不值得写，因为它们正在测试琐碎的功能。示例是getter / setter，和/或编译器/解释器将立即捕获的内容。相反的假设是“有趣的”代码值得测试。
答案 0 :(得分：8)
代码区域的覆盖水平应该与变化的可能性和依赖于它的功能量的组合成正比。
例如，我们在基本控件类的核心有一些相当复杂的解析逻辑。我们对绝对 piss 进行单元测试，因为它必须处理来自我们影响之外的系统的输入（更改的可能性很高）+我们所有的UI控件都依赖于它的稳定性。基础中最微小的调整涟漪，并通过继承和依赖的层次放大。
答案 1 :(得分：2)
单元测试验证在层之间传递的数据经常添加最多值
UI＆lt; ----＆gt;业务＆lt; ---＆gt;数据
答案 2 :(得分：1)
我发现获得最多回报的测试是测试先前发现的错误的测试。在我看来，如果一个团队除了在修复错误时添加回归测试之外什么也不做，他们会比其他任何测试策略都更有效。
通过测试已被破坏的东西（并彻底测试），您知道您正在测试易受破坏的区域。
这当然假设您正在测试在开发期间中断的事情，而不仅仅是等待QA报告在部署之后涓涓细流等等。
答案 3 :(得分：1)
当问到这个问题时，我毫不怀疑像硒测试这样的功能测试提供了最大的商业价值。 selenium（web）测试点击应用程序并断言用户故事/用例定义的预期行为。这些测试断言，您的软件试图与客户沟通的主要“事情”是好的。
如果这些东西不起作用，您的客户就会对您生产可信软件的能力失去信心，从而带走了相当大的商业价值。
现在可能会有相当多的细节，这些测试没有涵盖，但我真的相信它们对于创建信任至关重要，尤其是在与大众市场交谈时。
答案 4 :(得分：0)
为了解决我自己的问题，这里是我发现值得测试的模块：
a）任何业务规则。在我当前的应用程序中，业务规则是从业务对象外部化的。
b）业务对象上的任何虚拟属性。这些虚拟属性通常涉及算法。
c）我们可以说明消耗的给定输入的预期产出输出的主要组件。通常这会渗透到集成测试中。
d）我们的开发过程要求我们检查单元测试中的新功能和错误修复。对于错误修复，我们尝试复制导致错误的确切内容，并在签入代码修复后显示单元测试可以通过。
e）我们从一种数据表示类型转换为另一种数据表示类型的任何转换层，例如POJO-XML
答案 5 :(得分：0)
在SO Podcast 41中讨论 - 此部分目前不在transcript。 博客中的回复包含对单元测试覆盖率值的进一步讨论。
- Joel担心过度的TDD（例如，从90％到100％的测试覆盖率）会减少可能使软件产品受益的其他活动的时间，例如更好的可用性或用户要求的其他功能。
- 单元测试绝对是一种“吃你自己的狗食”的形式，并记录你的系统行为。即使您完全忽略了测试的实际结果，它们仍然作为文档很有价值，并且可以为您的代码库提供全新的外部视角。
- Joel注意到测试UI（Web或可执行文件）与测试UI背后的代码的难度。执行此操作的经典方法可能在“UNIX编程的艺术”中有记载，您可以从命令行应用程序开始，该应用程序接收并吐出文本。 GUI只是一个粘贴在命令行应用程序之上的层，从而导致完美的可测试性 - 但从长远来看，可能不是那么棒的应用程序。哪个更重要？
答案 6 :(得分：0)
所有合理的单元测试都是有价值的，但那些在我的经验中节省最多时间，从而产生最佳ROI的单元测试是针对错误修正的单元测试。主要是因为错误修正适用于代码中最困难/最脆弱的部分。
答案 7 :(得分：0)
TDD可以帮助您更快地编写代码，因此只有TDD在更快的速度下才能提供更多的商业价值。 ;）
答案 8 :(得分：0)
可在许多地方重复使用的测试。我当前项目的例子：
即使是对单元测试持怀疑态度的程序员也喜欢这些，因为他们可以用最少量的工作来使用它们 - 在某些情况下，它会引导他们自己编写单元测试。