java – 测试私有变量 – 总是不好的做法？

为了给出一些背景知识,我已经学习了大约10个月的java,所以我真的没那么有经验.我最近读过一些关于如何测试私有方法和变量的不良做法.

在完美的世界中,你不应该这样做,因为它暗示了糟糕的设计 – 但是,我正在使用遗留框架,其中大多数方法都是通过反射来调用的,这是糟糕的设计,但无论如何我都无法改变它.请不要回复说“你应该重新设计代码”,因为我无法改变框架的工作方式.

我想测试一个’flow’类以某种方式运行并根据私有变量的状态调用正确的方法,我想确保某些方法将私有实例变量设置为正确的值,如果另一个私有变量有一定的价值.当我将来对类进行更改时,我就可以确保类的流/行为没有被破坏或改变.

现在,因为流程主要基于私有实例变量的状态,并且因为测试私有实例变量的状态不好 – 我怎么测试类？

测试所有工作的私有变量的方法：

>在代码末尾实现默认访问getter和setter,并将junit测试类放在同一个包中.清楚地评论它们应该仅用于测试.
>使实例变量默认访问而不是私有,并将junit测试类放在同一个包中.无论如何,同一个包中的其他类都不会实例化此类.
>通过反射测试私有变量 – 我失去了IDE功能,因为如果我更改变量的名称Eclipse将不会重构,并且可能是将来手动更改字符串以匹配要测试的类中的变量名称的痛苦.

上面三个中的哪一个是“较小的”邪恶使用？是否更好地测试私有变量然后根本没有测试？

解决方法:

私有领域的状态与班级的正确运作无关.你不应该测试私有变量.

测试类的功能,而不是它是如何做的.

如果要测试类是否正确设置其内部状态,那么它在此之后以特定方式运行,然后调用设置状态的方法并测试之后的行为是否正确.

如果需要1000次测试来确保它们无关紧要 – 它们只是单元测试,所以它们会很快.

未来的程序员可以自由地改变班级的内部运作,只要该班级的合同得到维护.

标签：java,unit-testing,junit,mockito,private-members
来源： https://codeday.me/bug/20190612/1225887.html