Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。編集部ソフトウエアがXML出力を作成する場合には、多くの根拠があります。XML文書は異なるアプリケーション間のデータ交換のために使われますし、webアプリケーションはわずかなXMLスニペットを使って(X)HTML出力を作成したりAJAXリクエストに答えたりします。XMLが生成されるところには多くの利用ケースがあるので、その出力は他のアプリケーションの部分と同様にテストされるべきなのです。生成されたXMLをテストするには幾つかの方法があります。その各々が分離して使用される際のフローを持っています。下記のようなことができます。生成されたXMLがDTDに対して、またXMLスキーマや、或いは他の文法的代替物に対して正当であると確認することができます。残念なことに、このような文法はいつも文書中に存在するとは限りませんし、もしあったとしても、どのテストも出力の構造のみをテストするだけで、その内容はテストしません。生成された出力を期待される結果と比較することができます。残念なことに、同じツリー構造の情報を示す2つのXML文書からシリアライズされたとしても、極めて異なっている可能性があります。子ノードを持たない要素が空の要素になることもあれば、オープニングタグとクロージングタグを使えばシリアライズできる場合もあります。ホワイトスペースや文字コードには違いがあるかもしれません。XPathクエリーを使い、生成された文書の部分的なコンテンツを抽出することができます。それらの価値を表明することができます。これは、テストする必要がある生成済みコンテンツの量が大きければ、退屈なものになるかもしれません。プログラム的に文書を処理できます。-例えば、そのDOMオブジェクトモデルを使い-そして各ノードのコンテンツをアサ―トするといったことです。このように記述されたテストは非常に具体的で、出力構造が変化する際には大きな調整を強いられるかもしれません。いずれのタスクにとっても既存のAPIはしばしば不便なのです。XMLスキーマに対してのみ正当であると立証できたのですが、一方でそれはバイトストリーム或いは文字ストリームからDOMドキュメントインスタンス或いはSAXイベントのインスタンスまで解析されたのです。XMLUnitXMLUnitはBSDライセンスの下で認可されたオープンソースプロジェクトです。XMLUnitは相関クラスの小さなライブラリを提供しますが、それは、前のセクションで概説された幾つかのXMLをテストする異なった方法のそれぞれを簡素化します。J/Nunitを使ってユニットテストを記述するのを簡略化するための特別なAPIが提供されますが、ライブラリそのものは、一切のテスティングフレームワークを使わずとも十分使用することができます。XMLUnitのJavaと.NETのバージョンがありますが、Javaのバージョンはより十分に発展を遂げ、より多くの機能を提供しています。この記事はJavaのバージョンについてのみフォーカスし、全ての例はJavaを使っています。Martin氏により設立され、彼ら自身のプロジェクトのためのテストフレームワークとして開発されました。JavaのためのXMLUnitの最初の安定したリリースは2003年の3月に行われました。この1.0のリリースに続く4年間、XMLUnitは多くのオープンソース、また同じくらい多くのクローズドソースプロジェクトで使われてきました。そのアクティブな展開は行き詰まってしまったのです。関連スポンサーコンテンツ同時に、XMLエコシステムに変更が加えられました。1.0のバリデーションクラスはDTDに強力にフォーカスし、XMLスキーマは補足部としてのみサポートされました。名前空間をサポートしなくなりました。2006年秋、XMLUnitの開発は再度着手され、XMLUnit1.1の最初のベータ版が2007年4月にリリースされ、最終リリースがもうすぐ出る予定です。このリリースを超える更なる開発についての議論がXMLUnitのメーリングリスト上でなされています。1.0にも当てはまるものです。XMLUnitへの入力としてのXMLを提供するXMLUnitのAPIは「幾つかのXML」を数種類の異なる形式を使って入力として受け取ります。Readers、Strings、InputSources、或いは直ちに解析されたDOMドキュメントインスタンスとして提供が可能です。XMLUnitはまたトランスフォームクラスを提供し、それは既存の入力(上記に記載した形式の1つを使って)へのXSLT変換に適用するために使うことが可能ですし、更なるテストにおいてこの変換の出力を使うことも可能です。XMLスキーマに対してXML文書を検証することができます。パッケージを活用することになる予定です。NGやSchematron或いは他の文法についても同様に検証を提供できるかもしれません。どの形式の検証についても、XMLUnitのValidatorクラスが使用されます。XMLスキーマに対する検証DTDの検証はXMLUnitのデフォルトの設定ですので、スキーマ検証は、ValidatorのuseXMLSchema属性をtrueに設定することにより明確に可能でなければなりません。XMLスキーマに対して検証を行うために、テスト下の文書はスキーマのURIを使ってXML名前空間を宣言しなければなりません。文書はまたXMLパーサーにスキーマ定義を見つける場所を教えるschemaLocation属性を提供します。xsi:schemaLocation="file:///opt/schemas/example.com/order.xsd"/>例1:名前空間宣言とschemaLocation属性を持つXML文書schemaLocationが与えられなければ、XMLパーサーは名前空間URIをURLとして使用し、そこからスキーマ定義を読み込もうとします。残念なことに、schemaLocation属性を提供することも名前空間URIとして有効なURLを使うことも実現可能ではないというケースがしばしばあります。URLもまた作用しないでしょう。幸いにもJAXP1.2(すなわちJava1.4)は隠れ機能を提供しており、スキーマロケーションをプログラムで提供可能にします。スキーマのロケーションはファイル或いはURLまた、かなりの量のバイトとして特定される可能性があります。XMLスキーマに対してXML文書を検証し、スキーマロケーションをプログラムで提供するXMLUnitは現在、XMLスキーマインスタンスドキュメントの検証をサポートするのみですが、スキーマ定義そのものが、有効なXMLスキーマであることを検証することはできないのです。将来のバージョンで大いにサポートを拡張するという計画があります。DTDに対して検証するXMLUnitは多くの異なるシナリオの中でDTDバリデーションをサポートします。その最も基本的なケースでは、テスト中の文書がSYSTEM識別子を提供するドキュメントタイプ宣言を含んでいます。>例3:SYSTEM識別子とPUBLIC識別子を持つDOCTYPE宣言を伴うXML文書このケースでは、パーサーは与えられた識別子を使って文書の場所を決めます。XMLスキーマセクション内で概説されているのと同様の理由で、これは望ましいことではないかもしれないので、XMLUnitはユーザー自身のSYSTEM識別子を提供することを可能にします。すれば、既存のSYSTEM識別子をオーバーライドすることもあるでしょう。SYSTE識別子を特定することにより、いかなるDOCTYPE宣言も含まない文書をも検証することができるのです。EntityResolverを指定することができます。Catalogへの問題解決を引き延ばすために利用することが可能です。uri="example5.dtd"/>例5:DTDロケーションを解決するためにOASISカタログを利用する幾つかのXMLを比較するXMLUnitが2つのXMLを比較すると、結果は下記の3つの状態のうち、1つになります。2つのXMLは全く同じである2つのXMLは類似している2つのXMLは異なっているXMLUnitは見つけた相違点のそれぞれを、復元可能か否か分類します(下記参照)。XMLは相違点が全く見つからなかった場合のみ等しいことになります。全ての相違点が復元可能であると判明した場合、文書は類似しているとみなされ、復元可能でない場合は、文書は異なっているとみなされます。デフォルトでは、XMLUnitはわずか数種類の相違点を復元可能とみなすのみです。2つの文書が同じ名前空間に異なるプレフィックスを使っているとすると、それらの文書は同一ではなく、類似しているとみなされます。検出済みの相違点のフルリストはXMLUnitのユーザーガイド(source)に掲載されています。驚くべきことの1つに、XMLUnitは2つの文書が同じ要素を異なる順序で含んでいる場合、それらを類似しているとみなすことがあります。actual);例6:2つのXMLを比較する例6の最終行は、XMLAssertクラスにより提供された便利なメソッドであるassertXMLEqualを示しています。3.xかそれ以上のコンビネーションのためのAPIを単純化します。注意すべきことは、”assertXMLEqual”とは少々、誤ったネーミングであり、類似性のためのテストを提供する方法であって、等しいことをテストする方法ではない、ということなのです。2つのXMLが類似しているが同等でない場合、assertXMLEqualは誤る可能性があるかもしれません。XMLUnitは比較結果をよりコントロールする幾つかの拡張ポイントを提供します。DifferenceListenerDifferenceListenerインタフェースを実装することにより、自分のコンテキスト中でどのタイプの相違が重要かを自分で決定することができます。要素順の相違を回復不能へ「アップグレード」するか、コメント中の相違を無視することを選ぶことになるかもしれません。});assertTrue(d.identical());例7a:2つのXMLを比較し、コメント中の相違を無視するコメントを無視するのは通常の要件のようなものですので、XMLUnitはそれらを完全に無視する単純なオプションを提供しています。actual)assertTrue(d.identical());例7b:2つのXMLを比較し、コメント中の相違を無視するElementQualifierXMLUnitが要素の順序を重要とはみなさないことを考えれば、既知ノードのどの子供が互いに比較される必要があるのか、常に明らかなわけではありません。デフォルトでは、XMLUnitは同じタグネームをもつ要素を互いに比較しようとしますが、時には、それが望ましからぬ結果を導いてしまうこともあります。上記の例では、要素であるテキストコンテンツは、正しい要素を選ぶためにそれらのタグネームに加えて使用される必要があります。これはElementNameAndTextQualifierを使って達成され得るでしょう。ElementNameAndTextQualifier())assertTrue(d.similar());例9:ElementNameAndTextQualifierを使用するElementNameAndTextQualifierは、XMLUnitの配布物の一部であるElementQualifierインタフェースの幾つかの実装方法のうちの1つです。その上、匹敵するノードを識別するロジックが非常に具体的であるならば、自分自身の実装を提供することもできるのです。DetailedDiff例は、今までのところ、2つのXMLが同一であるかどうかについてのみ有効でした。2つのXMLを比較するもう一つの使用例は、相違点の全てを列挙するものです。l.size());例10:2つのXMLの全ての相違点を見つけるDetailedDiffはDiffのサブクラスの1つですので、2つの文書を類似しているものまたは異なっているものに分類する際に使用することが可能です。DetailedDiffとは異なり、Diffは修復不能な相違点に遭遇するやいなや、比較プロセスを中止します。したがって、全ての相違を見つける必要がなければ、パフォーマンス向上のためにDiffを使用すべきです。DiffもDetailedDiffも2つのXMLの間の相違をオンデマンドで算出し、結果を格納します。このことは、もし異なるセットのオプションを使って比較を繰り返したい場合には、新規のDiffインスタンスを作成する必要があることを意味します。その他の設定のオプション殆どのXMLUnitの設定は、静的メソッドのXMLUnitクラスを使って行います。値が明示的にリセットされない限り、デフォルト値をどのように変更しても適合するでしょう。ユニットテストケースのデフォルトの設定を変更するならば、各テストの後でそれらをリセットすることが適正な実践です(例えば、JUnit3.xを使うtearDownメソッドの場合など)。したがって、異なるテストは互いに影響を及ぼしません。変更したいオプションは空白の対処です。actual);assertTrue(d.identical());例11:エレメントコンテンツホワイトスペース上記例では2つのXMLは異なっているとみなされるでしょう。それは、1つ目のエレメントはテキストがネストしており(改行の文字)2つ目はそうでないからです。XMLUnitのignoreWhitespaceプロパティをtrueに設定すれば、この相違を回避し、2つの文書は同一であるとみなされるでしょう。その他のオプションとしては、コメントを無視するものや、CDATAセクションや「通常の」ネストしたテキストを1種のコンテンツとして処理するものを含んでいます。下記の例はどちらの表現もパスすることになります。Tests従来のXMLUnitは自身のXSLTベースのXPathエンジンを使っていました。1.3のjavax.xml.xpathが実行時に使用可能であればこれを支持し、そうでなければ内部のものに後退する予定です。NodeList或いは文字列として取得することをサポートします。通常は、1つの結果のみを望むのであれば、後者の形式の方がより適切です。この結果は属性の値であるかもしくはネストされた要素テキストです。doc).getLength());例13:XPathクエリーをテストする特に文書が同時に幾つもの名前空間を含んでいる場合には、XMLUnit1.0のXPathエンジンは名前空間型の文書には適切に機能しません。1.1はNamespaceContextインタフェースと実装に基づく簡潔なMAPを取り入れ、これがプレフィックスをURLにマッピングするのに役立つでしょう。doc).getLength());例14:ネームスペースド文書上のXPathクエリをテストするNamespaceContextを使用する際は、次のことに注意することが重要です。それは、ネームスペースのURLのみが意味をなすのであり、プレフィックスはそうでない、ということです。NamespaceContextsで提供されるプレフィックスはXPathセレクターに適用するのであり、文書に対してではありません。文書内では、プレフィックスは完全に無視されるのです。DOMツリーにおけるプログラムのテスト時折、生成されたXMLがあらかじめ定義された結果と比較することが非常に困難であり、個別にテストしなければならないノードがあまりにも多くあるために、XPathを使って各ノードをテストするのは非常に複雑になってしまうことがあります。このような状況のためにXMLUnitは生成されたXMLの各ノードを簡潔なインタフェースを使ってプログラムでテストできる、非常に強力なテスト方法を提供します。下記の例では、生成されたXMLは全てのアイテム要素のid属性において1つのGUID(8つの16進数で表現された)を含むと仮定されます。テストは属性の値が期待されたフォーマットにマッチすることを検証し、idが生成された文書にとってユニークであることを検証します。}}例15:XML文書の正当性をNodeTesterを使って検証するひとまとめにするXMLを生成するどのソフトウエアでも、出力機能やその他の機能についてテストができなければなりません。XMLをテストするには、幾つかの異なる方法が選択可能ですし、しばしば1つ以上の方法の組み合わせの方がベストな結果をもたらします。単純なケースでは、生成された出力を期待される出力と比較することで十分かもしれませんが、より複雑なケースでは、出力構造の正式な検証と、XPathクエリ(少量の出力の場合)を伴うコンテンツのテスト若しくはプログラムによるテストを組み合わせるべきです。Javaの中でXMLを処理するためのAPIは、しばしば使いづらいものですが、XMLUnitは本記事内に概説された全てのテスト方法について簡素化したAPIを提供しています。本記事は、XMLUnitの全ての側面をカバーしたものではありません。SAXParserクラスの実装によるサポートが存在します。TestCaseを拡張し、XMLAssertに似ているメソッドを提供するXMLTestCaseというクラスもあります。XMLUnitについては、プロジェクトのwebサイト(英語)とユーザーガイド(英語)で更に学ぶことができます。GmbHの開発責任者です。.NETプラットフォームをベースとしたアプリケーションのアーキテクチャと開発に対する責任を負っています。Antを含む幾つかのオープンソースプロジェクトの寄稿者でもあります。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。