1

JUnitテストにXMLUnitを使用していますが、特定の型の代替 (ただし同等の) レンダリングに関連する違いを無視するように構成したいと考えています。たとえば、フィールドの場合。完全なソリューションでは、テストが XSD 対応である必要があると思います。これにより、各フィールドのタイプが認識され、すべてのケースで微妙な比較が行われます (例: / forおよびおそらくデフォルトの属性値まで説明することさえあります)。いずれにせよ、これらの誤報なしにテストを実行できるように、回避策を喜んで受け入れます。3.143.140xs:floattrue1xs:boolean

SSCCE (簡単に再現できるように JUnit 機構なし) を以下に示します。

import org.custommonkey.xmlunit.XMLTestCase;
import org.custommonkey.xmlunit.XMLUnit;
import org.custommonkey.xmlunit.Diff;


class XMLTestCaseConcrete extends XMLTestCase {
}


public class FooMain {

    public static void main(String args[]) throws Exception {
        String s1 = "<a>180</a>";
        String s2 = "<a>180.0</a>";
        Diff diff = XMLUnit.compareXML(s1, s2);
        System.out.printf("difference below:\n------\n%s\n------\n", diff);
        XMLTestCase xmlTest = new XMLTestCaseConcrete();
        xmlTest.assertXMLEqual(s1, s2);
    }    
}
4

2 に答える 2

4

XMLUnit はスキーマに対応していないため、完全なソリューションはかなり複雑になります。行く方法は、カスタムを実装することですDifferenceListener。

このexampleパッケージには、FloatingPointTolerantDifferenceListener任意のテキスト ノードまたは属性に必要な処理を行う が含まれていますが、数値のように見えるすべての処理を行います。他のスキーマ タイプやデフォルト値は処理しません。

于 2015-02-03T18:48:01.733 に答える
1

最後に、(内部化中に) カスタム Java クラスを使用してこれをアプリケーション層に実装しました。これは、元xs:floatの正確な表現を「記憶」するStringため、後続のシリアル化中にまったく同じ文字列形式が使用されます (もちろん内部化後にアプリケーション ロジックによって変更されていません)。xs:float事実上、このソリューションと、Java オブジェクト層で s をs として扱う単純で単純なソリューションとの唯一の違いは、特殊化された のような型java.lang.Stringを使用して提供される追加の意味情報です。Float

いずれにせよ、このソリューションにより、@Dave が元の質問へのコメントで提案したテスト アプローチと、一連の内部化とシリアル化の後に同一の XML を生成する必要があるというより厳密なテストの両方を使用できます。

于 2015-02-07T14:24:49.107 に答える