複雜的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測試案例

回答

相關問題