我们是否可以仅仅为了方法级别的单元测试而将方法的访问说明符从私有更改为默认值

问题描述

我可以找到许多关于为什么不应该公开方法的问题/答案。但我在 Java 中找不到任何特定于“认”的内容

解决方法

'default',即没有修饰符,在 Java 中意味着 package private。只有同一个包中的类才能访问它。有时需要在与该类的其余部分分开的单元测试中测试用于该类的私有使用的内部方法,以便通过清晰、简洁和简单的测试覆盖所有代码路径。当您这样做时(结果是可以更轻松地维护更清晰的测试代码),可以将该方法标记为包私有。

This 并不是一种罕见的策略。由于唯一可以使用此方法的类必须驻留在同一个包中,因此您仍然可以对其使用进行充分的控制。

我个人建议只对不依赖于其父类状态的 static 实用方法执行此操作。它也是测试抽象类中静态方法的一种非常有用的技术。

请注意,在某些情况下,需要测试私有方法可能意味着需要将类的该部分拆分为单独的类。 This discussion 显示了一些常见的观点,从 strict OOP adherencepragmatism。您通常有可能打破该方法并将其变成适当的公共静态实用程序,但这并不总是有意义,并且它不一定会导致更易于维护的代码。

,

UnitTests不是测试代码,它们测试公共可观察行为,即:返回值与依赖项的通信

Public observable 不一定意味着 public 方法,但通常是。我们只是简单地测试其他代码在使用当前单元作为依赖时会调用的方法。

非公共方法(不打算被其他代码调用)是有助于单元行为的实现细节。因此它们是隐含的睾丸。

请记住,单元没有连接到方法。 它甚至可能是作为“入口点”的单个类后面的一组类。 单元是所有可能因相同(非技术)原因而更改的代码,即业务需求的更改。

这里的重点是实现细节可能会改变,而期望的行为(以及UnitTest)不会改变。我们进行此类更改以改进代码设计(解决代码重复、应用设计模式等)。我们称它们为重构(这是测试驱动开发的第三阶段micro cycle)。这样的重构正是我们最需要 UnitTest 的时候,因为当我们不改变它们时,它们保证被测试代码的期望行为仍然存在。