一些逻辑路径本身是不可测试的吗？

Question

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

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

Answer 1

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

Answer 2

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

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

这里的权衡是编写测试的努力与在自动化测试中使用特定代码片段的好处。如果您认为成本效益比很大且失败的可能性微乎其微，您可以将其作为特殊的手动测试，对未来的开发人员进行评论并立即手动验证。我说要务实，如果你花了30-40分钟开发人员的大脑时间试图让它受到考验，也许你需要退后一步并重新考虑你的策略。看看Michael Feather的“有效使用遗留代码”，以克服可测试性障碍的一些建议。

Answer 3

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

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

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

Answer 4

我刚刚尝试回答你原来的问题（并且在半空中碰撞，其他人更简洁地说同样的事情，或者至少是大部分事情;-)。无论如何，肯定存在过于僵化的框架（感谢private和朋友），如果你不能使用内省来解决这个问题（尽管做了所有适当的咒语），那么你只是在使用一种过于僵化的语言，也是一种框架。

如果在支持动态语言的整个系统（如现在的.NET）中出现这种情况，例如IronRuby和IronPython，我会感到惊讶 - 也许如果C＃不会让你通过内省绕过可访问性限制，动态语言可以服务。

那就是说， 肯定有可能让整个环境设计得那么糟糕而且如此严格，以至于无法对某些事情进行单元测试 - 尽管我并不完全相信在你目前的情况下就是这种情况。

Answer 5

有些东西无法在自动单元测试中进行测试，因为语言/框架/情况只是不公开。处理这种情况的方法是尽可能地减少该区域，并使其保持如此简单，以至于以后不太可能成为错误或行为变化的来源。

测试不仅仅是单元测试，还有单元测试不包括那些领域（如验收测试，QA等）。