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 test class with many private methods不是同一个问题，我的问题不是是否有必要测试私有方法，而是什么应该是更好的设计

Answer 1

我认为好的选择是用户和购物卡分开的逻辑。如果您同意我的意见，您可以将购物卡逻辑移到不同的类，然后您可以在测试中模拟这个逻辑，然后为getUsers()编写这样的测试：

public class UserTest {

 @Mock
 private ShoppingCard shoppingCard;
 private User sut = new User();

 @Before
 public void setUp(){
    MockitoAnnotations.initMocks(this);
 }


 @Test
 public void shouldReturnUsersEmptyListWhenCardsEmpty(){
    //given
    when(shoppingCard.getShoppingCards()).thenReturn(Collections.emptyList());

    //when
    final List<User> result = sut.getUsers();

    //then
    assertEquals(0, result.size());
 }
}

Answer 2

最后，这是关于“纯洁”和“真实世界”的平衡？！

意思:如果您坚持使用私有方法，那么这将阻止您进行部分模拟(例如)。它阻止了你直接测试这个方法。

就我个人而言，在这种情况下，我有时会采取务实的态度:简单地让其他方法包受到保护(而不是私有的)。然后您可以从单元测试中访问它，并且在必要时，使用Mockito间谍来部分模拟这些方法。

“真实世界”设计解决方案:考虑一下“获取购物清单”是否值得在自己的上完全支持。其实，这么“复杂”的活动听起来很奇怪.作为一种私人的方法。这样做的结果可能是:您开始复制代码。如果有one中央服务(类)为您提供“购物列表”，那么任何需要该列表的代码.能从那里得到它。

Answer 3

如果方法应该是私有的，则不应该对其进行单元测试。这给您留下了两个选项：

• 将getShoppingList()公之于众
• 不要单元测试getShoppingList()

如果getShoppingList()的正确性是整个应用程序工作所必需的，那么您应该公开它并为它创建单元测试。

但是，如果只有代码调用它，然后处理它，并且这些方法是面向用户的，那么您可以简单地测试这些方法，并确保它们按照预期运行。这就被动地保证了getShoppingList()按预期工作。

假设您有一个错误，使getShoppingList()抛出某种异常。然后，在对getUsers()的测试中，您应该会看到这个异常被抛出(假设它调用了getShoppingList() )。