2016-05-16 25 views
0

私は、クラス内のプライベート静的最終文字列フィールドを嘲笑するのが困難です。ここに私のJavaのサンプルコードです:Mockプライベート静的最終文字列Mockitoを使用して

public class Fruit { 
private static final String FRUIT = "apple"; 

public void getFruit() { 
    System.out.println("I like " + FRUIT); 
} 

}

そして、私は「りんご」の「マンゴー」からFRUITの値を変更することができるように、私はFRUIT変数を模擬するためにMockitoを使用。ここではそのために私のテストで:

public class FruitTest { 
@Test 
public void testFruit() throws NoSuchFieldException, SecurityException, Exception { 
    setFinalStatic(Fruit.class.getDeclaredField("FRUIT"), "mango"); 
    Fruit fruit = new Fruit(); 
    fruit.getFruit(); 
} 

static void setFinalStatic(Field field, Object newValue) throws Exception { 
    field.setAccessible(true); 
    Field modifiersField = Field.class.getDeclaredField("modifiers"); 
    modifiersField.setAccessible(true); 
    modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); 
    field.set(null, newValue); 
} 

}

私はSystem.out.println("I like " + FRUIT); を行うときに、それはマンゴーを印刷しますが、まだそれはリンゴを印刷している期待していました。私は本当にありがとう、誰かが私を助けることができる場合は、このようなMOCKITOだけではなく、PowerMockなど

+2

'Fruit'クラスの動作は常に' apple'を返すことになります。したがって、私はあなたがこれを変更するために探しているとは思わない。変数型の果物を返す可能性がある場合は、フィールドを 'static final'にしないで、' when() 'を使って必要な振る舞いを模倣してください。 –

答えて

0

コンパイル時の定数は、最適化のためにjavacによってインライン化することができます。あなたのFruitクラスを次のように変更した場合:

public static class Fruit { public static final String FRUIT = getFruit();

public static String getFruit() { 
     return "apple"; 
    } 



} 

それは setFinalStatic(Fruit.class.getField( "FRUIT")、 "マンゴー")との結果マンゴーが表示されます。 System.out.println(Fruit.FRUIT);

0

私はいくつかの静的フィールドを最近嘲笑して見ましたが、私はあなたがpowermockの助けなしにしようとしていることをすることはできないと思います。なぜあなたがしたいと思うかもわかりません。プライベート静的最終フィールドは定数であり、定数を変更する必要がある本当の理由はありません。そうしようとするすべてのテストは、間違ったことをテストしようとしています。

0

定数の値を変更するのは良い方法ではありません。それがもっと何か、私は不可能だと思います。しかし、フィールドの値を変更する場合は、修飾子 `finalを削除してください。

0

の最終は、その文字列が作成されるとその値を変更することはないと正確に記述しています。これはJavaで定数を取得する方法です。 getFruitメソッドは常に "apple"を返します。 Mockitoはそれであなたを助けません。このメソッドをテストする場合は、常に "apple"を返すことをテストする必要があります。そしてあなたのケースでは、あなたが戻ってきたものが一定の値であるので、メソッドが静的であるかどうかは関係ありません。リフレクションを使用することは良い考えではありません。これは実際にコーディングの練習が悪いだけでなく、今後の変更を適切に管理する方法がないためです。膨大な量のメンテナンスを必要とする侵略的なコードであり、実行時にそのメソッドを変更して「テストできる」ようにするためには、常にいくつかの行を生成します。すべての実際のケースでは、当然の理由がある場合や、アーキテクチャが改善する必要がある場合を除き、単体テストでのリフレクションは必要ありません。反射は学問的なものであり、あなた自身の注入システム、嘲笑ツール、またはそのようなコーディングを必要とするものを構築している場合には、より多くのものです。

関連する問題