我并不总是照本宣科。有时需求/要求也决定了您的方法。
就在几天前,我遇到了这种情况。尽管我正在编写Java
代码,并且我的答案基于 Java,但无论您考虑哪种编程语言,它都可能仍然相关。
在尝试为现有的(旧的)巨大类(代码覆盖率 <40%)实现良好的代码覆盖率时,我不得不编写几个测试用例,因此注意到了一些事情:
1)很少有本应是“私有”的方法被赋予“默认”(包级别)访问修饰符,以便可以对其进行测试。(使用JUnit 4)
---结果证明这些方法是错误的方法'应该是“私人的”。我不得不将它们更改为“私有”并修改测试用例。
2)为了增加代码覆盖率,我不得不调用公共方法并测试深层的“私有”方法。为此,我必须阅读/理解整个庞大的课程。(这个类只有 2 个公共方法和大约 15-20 个私有方法,很少有 4-5 个“级别”深度的方法调用)。
---正如您可能已经发现的那样,这太复杂了。毫无疑问,这些私有方法中的很多都变得难以测试:(
最后,我厌倦了阅读所有这些旧代码,并继续单独测试每个方法(使用“反射”测试私有方法)。在一个古老而庞大的系统中,这很有意义。
我的每个单元测试都确保它只测试一种方法的正确性。
如果任何方法未能达到预期效果,那么通过这种方式修复任何错误非常容易。
当然,这里可以争论说应该尊重封装,我的测试用例应该只调用公共方法。
但是,当有一个深入 5 层的私有方法没有做预期的事情时怎么办?您如何在旧代码中找到此错误!!!您不希望每种方法都经过测试吗?
在这种情况下,类没有机会改变其业务逻辑。因此,不存在维护测试类的问题。
尽管这个类是众多重构的绝佳候选者,但当您接近代码冻结时,您不会想接受它!:)
简而言之,答案可能因情况而异。根据您的需求/要求,您/您的团队将成为这方面的最佳决策者,因为您将是最了解您的系统的人......希望 ;)