代码之家  ›  专栏  ›  技术社区  ›  jpoh

有些逻辑路径本身是不稳定的吗?

  •  4
  • jpoh  · 技术社区  · 17 年前

    here my example ; 简单地说,我希望能够处理具有特定错误代码的ManagementException,但我似乎不可能设置一个抛出类似ManagementException的测试)。

    那么,我们如何应对呢?我们是否仅仅接受某些逻辑路径不稳定的事实(因为我们正在使用的框架或当前可用的测试框架的限制)?

    5 回复  |  直到 9 年前
        1
  •  2
  •   Robert    17 年前

    我不认为您可以说任何东西在逻辑上都是不稳定的,但是您肯定会发现,在代码中,测试它们所需的工作最好花在其他地方。

        2
  •  2
  •   Gishu    17 年前

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

    这里的权衡是编写测试的努力与在自动化测试下使用特定代码的好处。如果你觉得成本效益比很大,失败的可能性很小,你可以把它写成一个特殊的手工测试,给未来的开发人员一个评论,现在就手工验证一下。我想说的是,务实一点,如果你花了几个开发人员30-40分钟的脑力时间来测试它,也许你需要后退一步,重新思考你的策略。看看Michael Feather的“有效地使用遗留代码”中关于克服可测试性障碍的一些建议。

        3
  •  1
  •   Assaf Lavie    17 年前

    因此,首先,我不会说一些逻辑路径是“不稳定的”——最多它们可能很难测试 . 您可能仍然可以使用一些严重的重载系统测试来测试这些有问题的路径中的大多数。

    考虑这一点——你所测试的任何东西都可以被认为运行在你的控制下的虚拟机中,你可以(理论上)模拟它的操作的每一个方面来测试你的软件。这对于大多数应用程序是否实用是另一个问题。

        4
  •  1
  •   Alex Martelli    17 年前

    private 如果你不能用内省来解决这个问题(尽管你已经做了所有正确的咒语),那么你只是在使用一种过于僵化的语言,以及一种过于僵化的框架。

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

    也就是说,它 是 当然,整个环境可能设计得如此糟糕和僵硬,以至于无法对某些东西进行单元测试——尽管我不完全相信在您当前的情况下是这样的。

        5
  •  0
  •   Carl Manaster    17 年前

    测试也不仅仅是单元测试,那些领域(如验收测试、QA等)也不包括在单元测试中。