我一直在使用TDD来驱动我目前正在进行的项目，并且结果相当令人满意。我遇到了一个问题（描述为here;仍然没有解决方案或任何建议！），其中有一些特定方法的某些方面可能无法进行测试（如my example;简而言之，我希望能够处理一个具有特定ErrorCode的ManagementException - 但我似乎不可能设置一个引发这样的ManagementException的测试）。某些逻辑路径固有地不可测试？
那么，如何处理呢？我们是否简单地接受这样的事实：某些逻辑路径是不可测试的（因为我们正在使用的框架或者当前可用的测试框架的限制）？
有些设计不适合可测试性，尤其是那些没有可测试性作为设计目标之一的设计。一般TDDed设计不属于这一类。
要回答你原来的问题，我已经发布了一个响应，涉及在请求的错误代码中使用反射插槽。然而，这可能不适用于所有情况，并不是一个通用的解决方案。
这里的折衷是编写测试的努力与在自动测试下使用该特定代码的好处。如果您认为成本收益比率很高，并且失败的可能性很小，那么您可以将其作为特殊手动测试进行编写，对未来开发人员发表评论并现在手动进行验证。我认为是务实的，如果你花费了30-40分钟的几个开发人员的大脑时间来试验它，也许你需要退后一步并重新考虑你的策略。查看Michael Feather的“与遗留代码有效地合作”，了解克服可测试性障碍的一些建议。
我不认为你可以说任何事情在逻辑上都是不可测试的，但是你肯定会发现在测试他们所需的努力会更好地花在其他地方的代码领域。
确保罕见但显着的硬件和系统错误得到妥善处理（这是OP正在讨论的内容）不太可能成为低回报领域 - 因此，如果需要，值得付出实质性努力（以及关于OP的具体案例已经提出）。 – 2009-07-06 04:08:09
这是一个很好的问题，我最近也发现自己正在考虑这个问题。所以首先，我不会说一些逻辑路径是“不可测试的” - 最多他们可能很难用自动单元测试进行测试。您可能仍然可以通过一些严重的重型系统测试来测试大多数有问题的路径。
请考虑这一点 - 您测试的任何东西都可以被认为是在您控制的虚拟机内部运行，您可以（理论上）模拟其操作的每个方面以测试您的软件。对于大多数应用来说这是否实用是另一个问题。
模拟某些特定的硬件和系统错误而没有模拟（毕竟他是针对具有特定错误代码的ManagementException）在我所知的任何虚拟机环境中都将是一个严重的实际困难。然而，一个虚拟机（也许带有黑客入侵的WMI ......）实际上是另一种可能性，尽管在时间和精力方面成本很高（但如果找不到更简单/更便宜的方法，也许值得）。 – 2009-07-06 04:08:53
我刚刚尝试回答你原来的问题（并且在与其他人一起在midflight中相互比较，更简洁地说相同的事情，或者至少大部分相同;-)。无论如何，肯定存在的框架太僵化了（感谢private和朋友），如果你不能用自省来解决这个问题（尽管做了所有适当的咒语），那么你只是使用一种语言也是如此刚性以及框架。
如果整个系统支持动态语言（比如现在的.NET），比如IronRuby和IronPython，那么我会感到惊讶 - 也许如果C＃不会让你通过内省来访问可访问性限制，动态语言可以服务。
也就是说，它是肯定有可能为整体环境设计得如此糟糕，如此严格以至于无法对某些东西进行单元测试 - 尽管我并不完全相信这种情况在你目前的情况下。
有些东西不能在自动单元测试中测试，因为语言/框架/情况只是不开放给它。处理这个问题的方法是尽可能减少这个区域，并且保持它的简单性，以至于不太可能成为后来的错误或行为改变的源头。
除了单元测试外，还有更多的测试，而且这些领域（如验收测试，质量保证等）也不在单元测试中。
我已经在你的链接q中提出了一个建议。 – Robert 2009-07-06 03:52:03