Unit testing 有些逻辑路径本身是不稳定的吗？

我一直在使用TDD来推动我目前正在进行的项目，结果相当令人满意。我确实遇到了一个问题（描述过；仍然没有解决方案或任何建议！），其中某个特定方法的某些方面可能无法测试（简而言之，我希望能够处理具有特定错误代码的ManagementException，但我似乎不可能设置这样抛出ManagementException的测试）

---

那么，我们该如何处理这个问题呢？我们是否仅仅接受这样一个事实，即某些逻辑路径是不稳定的（因为我们正在使用的框架或当前可用的测试框架的限制）？

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

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

因此，首先，我不会说一些逻辑路径是“不稳定的”——最多它们可能很难用自动单元测试进行测试。您可能仍然可以用一些严重的重载系统测试来测试这些有问题的路径

---

考虑一下——你测试的任何东西都可以被认为是在你控制下的虚拟机中运行，你可以（理论上）模拟它运行的各个方面，以便测试你的软件。这对大多数应用程序是否实用是另一个问题。

我刚刚尝试回答了你最初的问题（在中途与其他人更简洁地说同样的话发生冲突，或者至少大部分是如此；-）。无论如何，肯定存在过于僵化的框架（感谢

私人

和朋友），如果你不能用内省来解决这个问题（尽管已经做了所有适当的咒语），那么你只是在使用一种过于僵化的语言，以及一种过于僵化的框架

如果在一个支持动态语言（如.NET现在所做的）的整体系统中出现这种情况，我会感到惊讶，比如IronRuby和IronPython——也许如果C#不允许您通过内省绕过可访问性限制，那么动态语言可以提供服务

---

这就是说，整个环境的设计很糟糕，很严格，不可能对某些东西进行单元测试，尽管我不完全相信在您当前的情况下是这样的。

有些东西不能在自动单元测试中进行测试，因为语言/框架/情况是复杂的处理这个问题的方法是尽可能减少这个区域，并保持它的简单性，这样以后就不太可能成为bug或行为改变的来源

---

测试也不仅仅是单元测试，那些领域（如验收测试、QA等）也不包括在单元测试中。

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

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

---

这里的折衷是编写测试的努力与在自动化测试下使用特定代码的好处。如果您觉得成本效益比很大，失败的概率很小，您可以将其编写为一个特殊的手动测试，作为对未来开发人员的评论，并暂时手动验证。我认为是这样的实事求是，如果你花了几个开发人员30-40分钟的脑力来测试它，也许你需要后退一步，重新思考你的策略。看看Michael Feather的“有效地使用遗留代码”中关于克服可测试性障碍的一些建议。

我在你的链接q中提出了一个建议。确保rare但是，如果能正确处理戏剧性的硬件和系统错误（这是OP讨论的问题），那么就不太可能是低回报的领域——因此，如果需要的话，值得付出大量的努力（并且对OP的具体情况提出了一些建议）。在不模拟的情况下模拟某些特定的硬件和系统错误（毕竟，他针对的是带有特定错误代码的ManagementException）在我所知的任何虚拟机环境中都将是一个严重的实际困难。然而，虚拟机（可能带有被黑客攻击的WMI…？-）确实是另一种可能，尽管在时间和精力方面代价高昂（但如果找不到更简单/更便宜的方法，这可能是值得的）。确实如此。你能测试你的软件在面对操作系统中的错误时是否会优雅地降级吗？是的，如果你准备编写一个有该错误的修改过的操作系统，你可以。但是很少有人会这么做。