Java：单元测试设计

Question

我已经实现了一个方法getUsers()，它基本上构造一个List<ShoppingCart>，然后创建一个List<User>：

public List<User> getUsers() {

   // construct a liste of List<ShoppingCart>

   ....

   // update 

   ...

}

的构造List<ShoppingCart>包含很多逻辑，所以我决定将这些代码移出并创建一个私有方法：

public List<User> getUsers() {

   // construct a liste of List<ShoppingCart>

   List<ShoppingCart> shoppingList = getShoppingList();

   // update 

   ...

}

private List<ShoppingCart> getShoppingList() {

  ...

}

现在我需要进行单元测试getUsers()。但是我意识到我很难得到它，List<ShoppingCart>因为它是一种私有方法。而且我不想公开，getShoppingList()因为我在其他任何地方都不需要它。

我认为我的代码中存在设计问题，对这些包含私有方法返回值的方法进行单元测试的最佳方法是什么？

谢谢。

更新

不，这与具有许多私有方法的 Java 测试类不同，我的问题不是是否有必要测试私有方法，而是更好的设计应该是什么

Answer 1

我认为好的选择是用户和购物卡的单独逻辑。如果您同意我的看法，您可以将购物卡逻辑移动到不同的类，然后您可以在您的测试中模拟这个逻辑，然后像这样编写测试getUsers()：public class UserTest {&nbsp;@Mock&nbsp;private ShoppingCard shoppingCard;&nbsp;private User sut = new User();&nbsp;@Before&nbsp;public void setUp(){&nbsp; &nbsp; MockitoAnnotations.initMocks(this);&nbsp;}&nbsp;@Test&nbsp;public void shouldReturnUsersEmptyListWhenCardsEmpty(){&nbsp; &nbsp; //given&nbsp; &nbsp; when(shoppingCard.getShoppingCards()).thenReturn(Collections.emptyList());&nbsp; &nbsp; //when&nbsp; &nbsp; final List<User> result = sut.getUsers();&nbsp; &nbsp; //then&nbsp; &nbsp; assertEquals(0, result.size());&nbsp;}}

Answer 2

最后，这是关于平衡“纯度”和“现实世界”？！意思是：如果你坚持使用私有方法，那么这会阻止你进行部分模拟。它会阻止您直接测试该方法。就个人而言，我有时会在这种情况下变得务实：只需将其他方法包保护（而不是私有）。然后您可以从单元测试访问它，并在必要时使用 Mockito 间谍来部分模拟此类方法。“现实世界”设计解决方案：考虑“获取购物清单”是否值得完全独立。实际上，这样一个“复杂”的活动……作为私有方法放在某个地方听起来很奇怪。这样做的后果可能是：您开始复制代码。如果有一个中央服务（类）可以为您提供“购物清单”，那么任何需要该清单的代码……都可以从那里获得。

Answer 3

如果方法应该是私有的，则不应对其进行单元测试。这给您留下了 2 个选择：公开getShoppingList()_不要单元测试getShoppingList()如果正确性getShoppingList()是整个应用程序运行的基本要求，则应将其公开并为其创建单元测试。但是，如果它仅由随后处理它的代码调用，并且这些方法是面向用户的，那么您可以简单地测试这些方法并确保它们按预期运行。这然后被动地保证getShoppingList()按预期工作。想象一下，您有一个错误导致getShoppingList()抛出某种异常。然后，在你的测试中，getUsers()你应该看到无论如何都会抛出异常（假设它调用getShoppingList().