OOP设计 - 私人修改器

时间:2012-03-04 12:42:20

标签: java oop unit-testing

我以为我知道何时应该使用private关键字。封装是这样做的原因,因此我努力使所有方法尽可能保密。

我刚刚写了一篇关于测试的帖子,并且被告知在我的私有方法上使用反射进行测试是一个坏主意,这是糟糕的代码设计。为什么会出现这种情况,我的密钥代码被隐藏/封装的事实是一件好事,应该不进行测试,因为这确实是我的公共代码所依赖的关键所在?

6 个答案:

答案 0 :(得分:6)

良好的测试尝试实现高代码路径覆盖,所以是的,测试私有方法是好事。但是你为什么要用反射直接打电话给他们呢? 这些方法是私有的这一事实通常表明存在使用它们的公共/受保护方法。因此,公共方法的测试意味着对私有方法的测试。

答案 1 :(得分:4)

由于私有方法不属于您的公共接口,因此您可以随时更改它们。如果您直接测试私有方法,则此类更改将破坏测试。这就是为什么你应该只测试代码的公共接口,而不是私有方法。

@Simon也提出了一个很好的观点。如果您遵循严格的测试优先方法,那么您将只编写公共方法。私有方法将主要通过重构创建(如果不是唯一的话)。

答案 2 :(得分:1)

封装的主要内容是它允许您在不破坏其他代码的情况下更改内部行为(即您将3个私有方法重构为1)。如果您测试这些内部方法,如果更改它们,您将破坏测试。此外,现在你在改变它们之前要三思而后行,限制你的自我改进。

如果您想测试您的方法是否正确,请测试它们对公共方法造成的影响。

答案 3 :(得分:1)

一个好的设计方法是从公共方法开始并对它们进行非常好的测试。在某些时候,你的公共方法会变得越来越大,那就是重构应该开始的时候。 使用重构来分解并从公共方法中提取私有方法。这将导致良好的私有方法覆盖,因为它们包含以前在单元测试所涵盖的公共方法中的代码。反思对您来说可能很容易使用,但想想那些将接管您的代码的同事,他们可能不如您好;)

答案 4 :(得分:0)

通常使用单元测试来测试类的公共接口。 许多聪明人不建议测试私有方法。 我同意这一点,因为测试所有功能是很多无聊的工作。 根据我的经验,公共界面的良好覆盖足以制作可靠的软件。

答案 5 :(得分:0)

相关问题