【问题标题】:Make member public to unit-test it公开成员以对其进行单元测试
【发布时间】:2015-11-18 19:33:38
【问题描述】:

我知道有很多关于类中私有成员的单元测试的问题。他们中的大多数人得出的结论是,拥有需要测试的私有成员是需要重构的设计缺陷(例如,参见here)。不过我还有最后一个问题:

当我将私有成员重构为新类时,它们会成为(公共)API 成员,但我打算避免这种情况。因此,通过简化我们的客户端类,我们通过设计一个新的公开可见的助手类来污染我们的 API。当然,也可以在程序集中编写测试代码,并将这些帮助程序放在内部,但因此我们也会将测试代码发送到生产站点。

我认为这个问题没有正确的答案,但也许您有一些很好的想法可以帮助避免这些情况?

【问题讨论】:

  • 恕我直言,不要为了可测试性而破坏/污染代码。我宁愿使用反射(如上面的链接)来测试一个私有方法,以确保没有任何东西被破坏。这很“丑陋”……但效果很好。我宁愿有一辆运行良好的丑车,也宁愿有一辆随时会在没有警告的情况下爆炸的法拉利。
  • 我真的不明白使用反射进行单元测试有什么问题。您要处理的不是生产代码,有时对私有方法进行单元测试确实有意义。
  • 我建议不要测试私有方法。通过公共 api 测试它们。见lostechies.com/chadmyers/2008/11/21/do-not-test-private-methods

标签: java c# unit-testing access-modifiers


【解决方案1】:

我打算把这篇文章写成一个编辑,但我得出的结论是我对问题做出了错误的假设。我认为我的问题是我将要测试的内容与测试的方式混合在一起。

要测试的内容:完成一定数量工作且值得测试的成员。 Access-modifier 在这里没有任何作用

如何测试:公众成员没有问题;但是对于私人成员来说有点棘手,但正如上面的喷嘴人回答所见,这是可行的。

话虽如此,正确的方法是将相关成员提取到新的非公共帮助程序类。为了能够测试这些成员,尽管不是公开的,我们使用前面提到的任何方法,反射、InternalsVisibleTo 甚至private accessors(在某些时候使用反射)。

【讨论】:

    【解决方案2】:

    关于 C#,你可以尝试最后一个技巧

    1. 让你的class/成员internal
    2. 在要测试的程序集中,打开 AssemblyInfo.cs 文件并通过添加以下属性使内部结构对您的测试项目/程序集可见:

    [InternalsVisibleTo("YourTestProject")]

    这会使您的成员在您的程序集之外不可见,除非为了在“YourTestProject”-Assembly 中进行测试。

    更多关于这个属性的信息可以在on MSDN找到。

    【讨论】:

    • 虽然这不会污染 API,但它仍然通过扩大其成员的访问权限来改变实际的类设计,只是为了测试。不过我想这在大多数情况下都可以。
    猜你喜欢
    • 2011-10-27
    • 2016-01-01
    • 2010-11-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多