2017-02-14 5 views
1

を使用して、これらの種類のメソッドをテストする方法はありますされている、それはこれをテストする必要があると感じていない一般的にはそれを実行時に実行され、この方法以来mockito

public void addListener(RepeatRejectAnalysis_Listener rralistener) 
{ 
    Save_Button.addActionListener(rralistener); 
    Cancel_Button.addActionListener(rralistener); 
} 
+0

他の質問でも述べたように、あなたの命名パターンは**標準ではありません**。あなたはそこでいくつかの学習をする必要があります。 – GhostCat

答えて

1

をテストすることが必要ビジネスロジックが存在しないため、メソッドのタイプが異なります。

しかし、あなたがそれをやりたいと思えば、同じ入力パラメータを持つ2つの異なるオブジェクトに対してaddActionListenerメソッドが呼び出されていることを確認できます。あなたのテストであなたのSave_ButtonCancel_Buttonを模擬する必要がある。この場合

// SETUP SUT 
RepeatRejectAnalysis_Listener yourRraListener = new RepeatRejectAnalysis_Listener(); 

// EXERCISE 
yourClass.addListener(yourRraListener); 

// VERIFY 
Mockito.verify(Save_Button, Mockito.times(1)).addActionListener(yourRraListener); 
Mockito.verify(Cancel_Button, Mockito.times(1)).addActionListener(yourRraListener); 

:このような類似。

2

ここでもMockingフレームワークは必要ありません。

ボタンにアクセスできる場合は、単にそのメソッドを呼び出すことができます。その後アサートの各ボタンは、その新しいリスナーがそのActionListenersのリスト内にあることを示します。言い換えれば

:あなただけモックもの、そのオブジェクトは、あなたのユニットテスト環境で作成する難しいです。例えば、データベースと話をしたいと思っているクライアントは、おそらくモックを必要とします。単純なJButtonはおそらくそうではありません。

ご理解ください:モックフレームワークは常にです。です。可能であれば、実動コード要素を直接アサート/検証する必要があります。したがって、ボタンをモックする代わりに、realボタンでテストを実行し、期待される動作を確認するためにそれらのインターフェイスを使用することに焦点を合わせます。

関連する問題