【发布时间】: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