8

テンプレートエラーが時折本番サイトに忍び込むという問題に直面しています。これらの問題を事前に把握するためのツールまたは戦略があれば、それをデリバリー パイプラインに追加できます。

4

3 に答える 3

4

私の経験から、テンプレートをレンダリングしようとすると、Freemarker には実際には 2 つのクラスのエラーしかありません (構成を無視します)。

  • テンプレート レベルでの単純な構文エラー
  • Java レベルで渡されたモデルに関する仮定が正しくありません

通常、lint ツールはコード内のエラーを検出しますが、lint ツールは基本的なテストの必要性を置き換えるものではありません。これは、本番コードで例外が発生しているため、ここで経験していることに対するはるかに優れたソリューションです。

良くも悪くも、誰がデータを操作しているか、誰がマークアップを操作しているかについての Freemarker の仮定は、さまざまなスキルセットを持つ別の人です。これが事実である (そして Java エンジニアリング リソースに余裕がある) と仮定すると、テスト プロセスの観点からこの問題に取り組むには 2 つの方法があります (厳密に言えば、両方が必要です)。

フロントエンドのテスト

前職では、このアプローチを単独で使用していました。基本的に、フロントエンド エンジニアは、編集されたテンプレートが 2 つのリストを含む構成パスに直接ある特別な Web フロントエンドでテンプレートをハッキングします。

  • レンダリングするテンプレート
  • レンダリングするデータ モデルのバージョン

「バージョン」は基本的に、ハードコーディングされた Java オブジェクトの 2 層セットであり、層 1 はすべてのテンプレートで一貫しており、層 2 はテンプレート固有のバリエーションでした。私たちのメールのほとんどはアカウント レベルの通知だったので、グローバル データ モデルを使用するだけで多くのマイレージと再利用が得られ、小さなことを掘り下げる必要はほとんどありませんでした。

利点

  • フロントエンド エンジニアは Java に触れる必要がないため、チームに HTML/CSS メイベンがあれば、意図した目的に使用できます。
  • バックエンド エンジニアは、テンプレートとその構造に応じて、多くのものをリサイクルできます。
  • 「アカウント」などの頻繁に使用される値を参照するときに、データ モデル変数名の統一性を緩やかに強制します (フロントエンド エンジニアは、別のバックエンド エンジニアが「間違った」名前を付けたため、期待した値が存在しないとイライラします)。

あまり良くない

  • これは基本的に手動テストであり、ある時点でエラーをキャッチできません。

バックエンドのテスト

もう 1 つの方法は、作成された各テンプレートのフォーム単体テストです。Freemarker の例外はすべてコンパイル時に発生するため、次のことのみを行う必要があります (初期設定を行った後)。

Template temp = cfg.getTemplate("myTestedTemplate.ftl");
temp.process(myTestDataModel, myIgnoredOutput); // No exceptions -> OK for us

この場合、結果は気にしないことに注意してください。コンパイルする必要があるだけです。これは重要です。なぜなら、Java でコンパイルされた出力のデバッグに簡単に行き詰まり、現在の問題を解決できないからです。前と同じように、おそらくここでも同じ 2 層の単体テストを実行する必要があります。

  • いくつかの一般的なモデルを使用してすべてのテンプレートをスモーク テストします (各テンプレートの取得はプログラムで実行できる可能性があります)。
  • 予想されるデータ モデルのバリエーション (設定の欠落、不完全なフィールドなど) を使用して個々のテンプレートをテストします。

利点

  • ビルド/デプロイ プロセスの一部であるため、テンプレートでの人的エラーを排除できます
  • Freemarker の使用方法に応じて、データ モデルが他のプロセスによって正しく生成されていることを確認することもできます (まだ行っていない場合)。

あまり良くない

  • フロントエンド エンジニアは、スタック トレースを読み取って何が失敗したかを特定する必要があります。
  • この方法を使用した開発は、ビルド プロセスに縛られてしまい、ページのリロードほど高速ではありません。

両方を行う時間がある場合は、単体テストを使用して、発生したエッジ ケースやその他の問題を処理し、次に開発用の Web フロントエンドを使用して、ページの開発に再コンパイルが必要ないようにすることをお勧めします。 . フロントエンドをバージョン管理する機能は非常に有益ですが、最初の目標はビルド プロセスでの本番環境でのエラーを防ぐことです。起動してから最適化し、すべて。

于 2012-02-13T23:11:35.910 に答える
1

テンプレートの構文エラーではなく、ランタイム出力エラーを意味する場合は、(壊れやすい) "expect-got" 統合テストのセットを使用できます。これがどの程度適切かは、テンプレートの複雑さとそれらがどの程度動的であるかによって異なります。単純な「煙」テストだけが必要な場合は、これがおそらく適切なソリューションです。

テンプレートごとに、少なくとも 1 つのテストを作成します。具体的/静的/事前指定された入力データと具体的/静的/事前指定された出力結果を使用する。この出力は、変更後に最初に手動で生成して検証する必要がありますが、それ以降は保存してテストをスクリプト化できます。テンプレートが固定入力として設定できない独自のデータ (日付など) を取り込む場合は、予想される出力からこれをマスクまたは削除します。各自動テストは次のことを行う必要があります。

  1. テンプレートごとに、少なくとも 1 セットの入力データから「得た」出力を生成します。
  2. 出力から予測不可能な可変領域をマスクまたは削除します。
  3. この「得られた」結果を、保存された事前検証済みの「期待される」出力と比較します。
  4. これらが同じでない場合、失敗を報告します。

正確な出力の等価性は、実装が最も簡単で、正しいことを保証します。必要に応じて、テンプレートごとに複数のテストを行います。私は頭が良くなろうとはしませんでした。退屈で反復的な作業をコンピュータに任せるだけでした。最初のパスでマスクする必要があるテンプレートの部分は無視します (一部のテストは、何もしないよりも優れています)。信頼性が向上し、努力する価値があると判断した場合は、後で明示的なテストを記述します (または、過去に間違って実行されたものに対して)。

このソリューションには、次の注意事項があります。

  1. 範囲が広すぎます。テンプレートまたはデータ モデルに変更を加えると、テストの更新が必要になる場合があります。「diff」を使用すると、手動で検証し、データ モデルやテンプレートが変更されたときにテストを変更する方法を決定するのに役立つ場合があります。

  2. コード拒否とモジュール性は、テストの問題を引き起こします。優れたモジュラー コードでは、1 つのコード変更ですべてのテンプレートのデータに影響を与えることができますが、静的テストでは、これが発生した場合、すべてのテストを個別に変更および再作成する必要があります。それを修正するためにやるべきことはあまりないので、コードがより良く、よりモジュール化されているほど、これにより多くの作業が発生します:(

  3. 洗練されたテンプレートはテストが困難です。数セットの静的データのみを使用して適切なテンプレート カバレッジを実現するには、問題が生じる可能性があります。これは、テンプレートが過剰な「処理」を行っており、実際にはテンプレートとしてのみ使用されていないことを意味している可能性があります。とにかく、それはおそらく良い考えではありません。

于 2012-02-11T19:41:07.737 に答える
-1

これを行うツールについては知りませんが、構文エラーを検出するには、すべてのテンプレート ファイルをnew Template("whatever", theTemplateFileReader);. 残念ながら、この方法では実行時エラー (存在しない変数/マクロ/インポートへの参照など) を検出することはできません。そのために を呼び出すこともできますがTemplate.process、実際のアプリケーションで使用するデータ モデルがなければ、もちろん意味がありません。

于 2012-02-01T10:54:38.717 に答える