データベースからフォーム定義を取得し、フォーム定義に従ってhtml、javascript、およびcssをレンダリングするJavaクラスがあります。これは、多くの「appendable.append（...）。append（...）」を使用してビルドします。エラーが発生しやすいhtmlスニペット。javascript、css、html要素はすべて動的であるため（フォーム定義に応じて）、Jspおよび一般的なテンプレートフレームワーク（例：FreeMarker）はここではオプションではありません。また、いくつかの理由により、GWTもオプションではありません。
このレンダラーの単体テストの簡単な方法は、予想されるhtmlコードをハードコーディングしてから実際の出力と比較することですが、テストは非常に脆弱です。
この種のhtmlレンダラーをユニットテストするための最良の方法は何ですか？
よろしくお願いします。
予想されるHTML値をハードコーディングすると、テストが脆弱になる可能性がありますが、おそらくほとんどのバグを検出できます。別のアプローチは、HTML出力に特定のキーまたは重要なタグが存在するかどうかを確認することです。このアプローチははるかに柔軟性がありますが、いくつかのバグを見逃す可能性があります。どちらを使用するかを決定するには、HTML構造が変更されると予想される頻度を検討してください。
ここで打たれるバランスがあります。テストが具体的であればあるほど、テストは最も脆弱になります。ただし、具体性が十分でない場合、テストでバグを検出することはできません。どのように具体的であるかについての感覚を発達させるには練習が必要です。
ただし、一般的に、脆弱なテストは非常に危険であるため、おそらく「より大きな悪」です。テストで多くの誤検知が報告された場合、それらを無視し始め、その後、それらは役に立たなくなります。キータグの存在を確認することをお勧めします。
私は2つのアプローチを取ります。まず、生成している個々のスニペットを確認します。テストでは、これらのコンポーネントが期待どおりに機能することを検証する必要があります。次に、作成された各ドキュメントが全体として有効であり、そのタイプに対して一貫していることを確認する必要があります。この検証を実行するサードパーティのツールがあります。いくつかの例については、 http：//www.w3.org/QA/Tools/を参照してください。
あなたが比較について言及したアプローチは良いアプローチであり、それはテストへの「ゴールデンマスター」アプローチと呼ばれています。
これを行うためにjunitと連携する検証ライブラリがあり、承認テストと呼ばれるプロセスを大幅に簡素化しますhttp://www.approvaltests.com
これは、diffレポーターまたはWebブラウザーのいずれかで結果やゴールデンマスターを開くレポーターを使用することにより、脆弱性から保護するのにも役立ちます。
あなたが探している電話は：
Approvals.VerifyHtml(yourHtml)
そして、あなたはどちらかであなたのテストを飾りたいでしょう
@UseReporter(DiffReporter.class)
@UseReporter(FileLauncherReporter.class)
@UseReporter({DiffReporter.class, FileLauncherReporter.class})