2011-09-09 10 views
4

私は次のようであるJUnitテストを持っている:のJUnitのassertEqualsの変更文字列

@Test 
public void testToDatabaseString() { 
    DateConvertor convertor = new DateConvertor(); 
    Date date = convertor.convert("20/07/1984:00:00:00:00"); 
    String convertedDate = convertor.toDatabaseString(date); 

    assertEquals("to_date('20/07/1984:00:00:00:00', 'DD/MM/YYYY HH24:MI:SS')",convertedDate); 
} 

テストが述べ失敗:期待値である理由特に興味深いの

org.junit.ComparisonFailure: expected:<to_date('20/07/1984[00:]00:00:00', 'DD/MM/YY...> but was:<to_date('20/07/1984[ ]00:00:00', 'DD/MM/YY...> 

は次のとおりです。

to_date('20/07/1984[00:]00:00:00',など...

テスト時の文字列リテラルがはっきりしている場合:

"to_date('20/07/1984:00:00:00:00',等...

誰もがこれを説明できますか? "[00:]"が追加されるのはなぜですか?ヘルプをよろしくお願いいたします。

+1

@ルーク・ウッドワード、ジョン7ありがとう、私はちょうどあなたの人が投稿する前にそれを考え出した。しかし、うまくいけば、この質問は将来誰かを助けるでしょう。 –

答えて

10

角括弧は、期待される文字列と実際の文字列の違いを強調しています。

JUnitは、:00の前後に大括弧を入れて、実際の文字列ではなく予想文字列にあることを強調します。同じ理由で、実際の文字列のスペースの周囲に角括弧があります。

3

JUnitは、読みやすくするために、括弧で囲まれていない文字列を文字列に入れているだけです。あなたのアサートは4セットの ":00"を探し、あなたの変数は3セットしか持っていません。

このSOの質問(Java: Is assertEquals(String, String) reliable?)に記載されているように、assertEqualsは渡すオブジェクトに対して.equalsメソッドを呼び出すだけです。