某些逻辑路径天生就无法测试吗？答案

【问题标题】：Are some logical paths inherently untestable?某些逻辑路径天生就无法测试吗？
【发布时间】：2013-09-04 23:37:14
【问题描述】：

我一直在使用 TDD 来推动我目前正在从事的项目，结果相当令人满意。我确实遇到了一个问题（描述为here；仍然没有解决方案或任何建议！）其中可能无法测试特定方法的某些方面（如my example；简而言之，我想能够处理具有特定 ErrorCode 的 ManagementException - 但我似乎无法设置一个抛出类似 ManagementException 的测试）。

那么，如何处理呢？我们是否只是接受某些逻辑路径不可测试的事实（因为我们正在使用的框架或当前可用的测试框架的限制）？

【问题讨论】：

我已在您的链接 q 中提出建议。

标签： unit-testing tdd

【解决方案1】：

有些设计不适合可测试性。尤其是那些没有将可测试性作为设计目标之一的设计。通常 TDDed 设计不属于这一类。

为了回答您最初的问题，我发布了一个回复，其中涉及使用反射来插入请求的错误代码。但是，这可能不适用于所有情况，也不是通用解决方案。

这里的权衡是编写测试的工作量与将特定代码置于自动化测试下的好处。如果你觉得成本收益比很大，失败的可能性很小，你可以把它写成一个特殊的手动测试，给未来的开发者一个评论，暂时手动验证它。我想说是务实的，如果你花了 30 到 40 分钟的几个开发人员的大脑时间试图让它接受测试，也许你需要退后一步重新考虑你的策略。查看 Michael Feather 的“有效使用遗留代码”，了解一些克服可测试性障碍的建议。

【讨论】：

【解决方案2】：

我认为你不能说任何东西在逻辑上都是不可测试的，但你肯定会发现在代码区域中测试它们所需的精力最好花在其他地方。

【讨论】：

确保正确处理罕见但严重的硬件和系统错误（毕竟这是 OP 正在讨论的）不太可能是低回报的领域 - 因此，如果需要（并且针对 OP 的具体案例提出了一些建议）。

【解决方案3】：

这是一个很好的问题，我最近也在思考这个问题。

所以首先，我不会说某些逻辑路径是“不可测试的” - 最多它们可能很难用 自动单元测试 进行测试。您可能仍然可以通过一些严肃的重型系统测试来测试大多数这些有问题的路径。

考虑到这一点 - 您测试的任何东西都可以被认为是在您控制下的虚拟机中运行，并且您可以（理论上）模拟其操作的各个方面以测试您的软件。这对于大多数应用程序是否实用是另一个问题。

【讨论】：

在不模拟的情况下模拟某些特定的硬件和系统错误（毕竟他的目标是带有特定错误代码的 ManagementException）在我所知道的任何虚拟机环境中都将是一个严重的实际困难。但是，VM（可能带有被黑的 WMI...？-）确实是另一种可能性，尽管在时间和精力方面非常昂贵（但如果找不到更简单/更便宜的方法，也许值得）。跨度>
确实如此。你能测试一下你的软件在面对操作系统中的错误时会优雅地降级吗？是的，如果您准备编写具有该错误的修改后的操作系统，您可以。但很少有人愿意这样做。

【解决方案4】：

我刚刚尝试回答您最初的问题（并在飞行途中与其他人更简洁地说同样的话发生碰撞，或者至少大部分内容；-)。无论如何，肯定存在过于死板的框架（感谢private 和朋友），如果你不能使用内省来解决这个问题（尽管已经完成了所有正确的咒语），那么你只是在使用一种语言框架太死板了。

如果在支持动态语言（如 IronRuby 和 IronPython）的整体系统中出现这种情况，我会感到惊讶（如 IronRuby 和 IronPython）——也许如果 C# 不允许您通过自省绕过可访问性限制，动态语言可以服务。

也就是说，确实有可能将整个环境设计得如此糟糕和如此严格，以至于无法对某些事物进行单元测试——尽管我并不完全相信你现在的情况就是这样。

【讨论】：

【解决方案5】：

有些东西无法在自动化单元测试中进行测试，因为语言/框架/情况对它不开放。处理该问题的方法是尽可能减少该区域并使其保持简单，以便以后不太可能成为错误或行为更改的来源。

除了单元测试之外，测试还包括更多内容，这些领域（例如验收测试、QA 等）也不包含在单元测试中。

【讨论】：