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 {

 @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 间谍来部分模拟此类方法。

“现实世界”设计解决方案：考虑“获取购物清单”是否值得完全独立。实际上，这样一个“复杂”的活动……作为私有方法放在某个地方听起来很奇怪。这样做的后果可能是：您开始复制代码。如果有一个中央服务（类）可以为您提供“购物清单”，那么任何需要该清单的代码……都可以从那里获得。

Answer 3

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

• 公开getShoppingList()_

• 不要单元测试getShoppingList()

如果正确性getShoppingList()是整个应用程序运行的基本要求，则应将其公开并为其创建单元测试。

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

想象一下，您有一个错误导致getShoppingList()抛出某种异常。然后，在你的测试中，getUsers()你应该看到无论如何都会抛出异常（假设它调用getShoppingList().