单元测试的包装类答案

【问题标题】：Wrapper-Classes for Unit-Tests单元测试的包装类
【发布时间】：2015-11-26 15:05:40
【问题描述】：

我可以编写一些单元测试并进行重构。我们正在使用 Hybris。你经常可以看到的是火车残骸。例如：cmsSiteService.getCurrentSite().getSlaveSalesOrganization() 等等。

现在编写单元测试并模拟响应，在这种情况下，我将首先模拟 CurrentSite 并声明 doReturn(currentSite).when(cmsSiteService.getCurrentSite)，然后声明 doReturn(slaveSalesOrganization).when(currentSite).getSlaveSalesOrganization()。

这个示例很短，但是使用 cmsSiteService 会在整个项目中发生。由于 cmsSiteService 是第三方 Hybris 类，我认为编写一个从 CMSSiteService-Class 继承所有内容的包装类会很好。在那里我可以编写一个方法 getSlaveSalesOrganizationFromCurrentSite(CMSSiteService cmsSiteService) ，我会在其中调用上面的所有内容。

这是推荐的还是设计上有更好的解决方案？

【问题讨论】：

我认为您的问题可能会通过一些实际示例更清楚。
你可能要找的是RETURNS_DEEP_STUBS，我猜？
我在代码中遇到了相同的模式，因此决定编写一个测试类来模拟所有常见模式并提供对模拟的受保护访问。然后，实际的单元测试都继承自那个“超级测试”，并且可以选择为各个项目添加模拟意义。
问题是，这不仅是为了让单元测试更容易，而且是用我的包装器替换普通的 CMSSiteService 类，在我的代码中。

标签： java junit mockito wrapper hybris

【解决方案1】：

听起来您走在正确的轨道上。您正在做的是重构代码以更好地遵守Law of Demeter，也称为“最少知识原则”。像您说的那样挖掘对象链是一种反模式，这正是您遇到的原因：当对象紧密耦合时，它们很难修改和测试。

理想情况下，如果允许您修改该代码，您应该将getSlaveSalesOrganizationFromCurrentSite 方法添加到您的CMSSiteService 类中。我认为创建一个包装器来简化丑陋的界面是一个很好的第二选择。那将是Adapter pattern 的实现。这是防止您自己的代码与（其他人的）蹩脚代码紧密耦合的好方法。

【讨论】：