复杂的Junit测试案例

我想为这个类创建一个JUnit测试。复杂的Junit测试案例

什么是最好的方式去测试不同的if-else语句。

我试过一些通用的单元测试用例。

public class ObjectClaimHistory { 

    private List<ObjectCollaborationClaimHistory> objectClaimHistory = new ArrayList<>(); 

    public void checkClaim(ClaimRequest claimRequest, Set<Integer> outOfDateCommits, int collaborationId, Integer parentCollaborationId, ClaimConflicts conflicts) { 
     Set<Integer> conflictingCollaborationClaims = new HashSet<>(); 
     Set<Integer> conflictingCollaborationBlocks = new HashSet<>(); 
     for (ObjectCollaborationClaimHistory collaborationClaimHistory: objectClaimHistory) { 
      if (!collaborationClaimHistory.checkClaim(claimRequest, outOfDateCommits)) { 
       conflictingCollaborationClaims.add(collaborationClaimHistory.getCollaborationId()); 
      } 
      if (!collaborationClaimHistory.checkBlock(claimRequest, outOfDateCommits)) { 
       conflictingCollaborationBlocks.add(collaborationClaimHistory.getCollaborationId()); 
      } 
     } 
     // After checking all histories create one commit conflict. Choose the closest collaboration. 
     if (conflictingCollaborationClaims.contains(collaborationId)) { 
      conflicts.addCommitConflict(claimRequest.getObjectId(), claimRequest.getClaim(), collaborationId); 
     } 
     else if (conflictingCollaborationBlocks.contains(collaborationId)) { 
      conflicts.addCommitConflict(claimRequest.getObjectId(), claimRequest.getBlock(), collaborationId); 
     }

来源

2017-07-11 Samuel Oyediran

我不太清楚这个测试如此复杂。你只要给它模拟版本的类（例如，总是返回false的CollabClaimHistory）并验证结果。 –

我们通常使用一些IDE并在测试类中编写一些代码。 “最佳方式”是什么意思？ –

如果我正确理解你的问题，然后...

你想控制的collaborationClaimHistory实例的行为使得一些测试场景则返回true和在别人为这些调用返回false：

collaborationClaimHistory.checkClaim(claimRequest, outOfDateCommits)
collaborationClaimHistory.checkBlock(claimRequest, outOfDateCommits)

您想断言添加到给定ClaimConflicts的commitConflicts是有效的。

看看代码我看到这个：for (ObjectCollaborationClaimHistory collaborationClaimHistory : objectClaimHistory)这让我怀疑objectClaimHistory被注入或发现ObjectClaimHistory。对于您的测试，您必须能够控制如何填充，以便它返回CollaborationClaimHistory的实例，您可以调整它们以满足您的测试场景。

这里创建ObjectClaimHistory当是其中假定objectClaimHistory被注入一个例子：

@Test 
public void someTest() { 
    CollaborationClaimHistory collaborationClaimHistory = Mockito.mock(CollaborationClaimHistory.class); 

    ObjectClaimHistory sut = new ObjectClaimHistory(Lists.newArrayList(collaborationClaimHistory)); 

    ClaimRequest claimRequest = ...; 
    Set<Integer> outOfDateCommits = ...; 
    int collaborationId = ...; 
    Integer parentCollaborationId = ...; 
    ClaimConflicts conflicts = ...; 

    // set up expectations on the collaborationClaimHistory instance which will be interrogated within the sut 
    Mockito.when(collaborationClaimHistory.checkClaim(claimRequest, outOfDateCommits)).thenReturn(true); 

    sut.checkClaim(claimRequest, outOfDateCommits, collaborationId, parentCollaborationId, conflicts); 

    // assert that the response (which is implicit in th post invocation state of conflicts) is valid 
    assertTrue(conflicts.hasCommitConflict(claimRequest.getObjectId(), claimRequest.getClaim(), collaborationId)); 

    // ... and repeat for other scenarios, multiple CollaborationClaimHistory instances etc 
}

来源

2017-07-11 15:36:56 glytching

非常感谢你 –

不客气 – glytching

。如果检查每个和else if语句，你将需要创建多个单元测试，并通过在每一种情况下的说法，每个if和else if语句，即期待您将创建4测试用例的方法并给它4个参数。另一种测试哪种方法不被推荐，并且是一种不好的方法，但相当快速和简单的方法是在每个if和else if语句中添加assertTrue语句，这将检查输入是否在运行时给出并且是正确的。让我知道如果你需要更多的帮助或示例代码

来源

2017-07-11 15:35:31

杠杆的setup（@Before）方法来创建健壮测试夹具，嘲笑具有对外部资源的依赖关系的合作者例如DB，队列。在测试类中创建成员变量以容纳测试协作者，并在setup方法中设置其状态。这给测试方法提供了根据给定测试需要改变它们的能力。
在每次测试中，必要时更换测试夹具以达到测试条件。由于测试只会因某个原因而失败，因此理想情况下只能更改测试夹具的一个方面。经过深思熟虑的测试夹具对于防止由不完整的测试设置引起的意外副作用有很长的路要走。剩下的就是调用被测试单元并确定预期结果。
使用代码覆盖率工具来跟踪您的进度。您会惊讶地发现您为生产方法编写了太多的测试。

如果您遵循这种方法，则需要较长的时间才能设置夹具，但在测试中本身会有较少的重复代码。奖励是，一旦灯具安装完毕，测试通常很短，很快就会完成，为将来添加更多测试打下良好的基础。

来源

2017-07-11 15:39:18 user6629913

复杂的Junit测试案例

回答

相关问题