10

テンプレート プロジェクトで繰り返し発生する問題があります。Template Builder でテンプレートを実行する以外に、自分の作業を実際にテストすることはできません。TBB のコードを変更した後、すべてのテンプレートを再テストする必要があるため、複数の異なるテンプレートで使用される TBB で作業している場合、これは大きな問題です (おそらくいくつかの異なるページ/コンポーネントが存在する可能性があります)。内容により若干異なります。）

TBB が再利用される大規模なプロジェクトでわかるように、必要なテストの量が多いため、TBB の変更には多くの時間がかかります。これに対する解決策を見つけたいと思っています。現在のTOM.NET (ほとんどのクラス/メソッドは内部) では単体テストが事実上不可能であることはわかっています。

私が調べた解決策の 1 つは、コア サービスを使用して、いくつかのテスト コンテンツを含むテンプレートのレンダリング プロセスを開始し、出力が期待どおりかどうかを確認することですが、これを実現するには非常に多くのコードが必要であり、不要なオーバーヘッドが発生すると思います (ケースを手動で再テストするよりも時間がかかりません)。また、個々の (またはサブセットの) TBB を使用して個別のテンプレートを (プログラムで) 作成しない限り、個々の TBB を実際にテストすることはできません。このソリューションの良い点は、開発中にローカル ラップトップでテストを実行できることです。ただし、Tridion サーバーに接続できると仮定します (テストを実行する前にコードを Tridion にアップロードする必要があるため、完全に理想的なソリューションとは言えません)。 ）。

テンプレートが（通常）非常に単純であるため、フロントエンドですべてのテストをほとんど処理できるDD4T / CWAを使用することも別の方法であることを私は知っています。

他のアイデアはありますか？

4

6 に答える 6

6

私は、単体テストではなく自動テストに重点が置かれていることに同意します（結局のところ、これは主にオブジェクト指向プログラミングに関するものです）。Tridionの作業では、データを変換することが重要です。データ変換をテストするために必要なのは、既知の入力を持ち、出力についてアサーションを作成できるようにすることです。私は何年にもわたってさまざまなアプローチを試してきましたが、これまでで最も効果的なのは次のとおりです。

1）すべてのテンプレートについて、テストコンテンツを専用のフォルダーに保持し、テストページを専用の構造グループに保持します。コンテンツはテストへの入力であり、テスト要件が変更されない限り変更されることを意図したものではありません。2）コンポーネントをページに配置します。ページを公開します。シンプルに保つ：多くの場合、単一のテストシナリオのページを作成できます。それが役立つ場合は、ページの公開を自動化できます。3）Webテストツールを使用して出力を確認します。これは、HtmlUnit、Seleniumなどです。

基本的に-Tridionは変換を実行するためのエンジンです。この部分に専用のテスト実行エンジンは必要ありませんが、出力のテストに使用すると便利です。

パッケージをモックするのは魅力的に聞こえますが、Vesaが言うように、それは膨大な量の作業になる可能性があります。私が概説した単純なアプローチは実際に機能し、重要なプロジェクトで証明されました。必要に応じて、テーマにバリエーションを追加できます。私が検討したものの、プロジェクトで行ったことのないことの1つは、青写真を使用してより分離性を高めることです。たとえば、コンポーネントテンプレートをローカライズして、静的で予測可能なコンポーネントプレゼンテーションを生成することにより、ページテンプレートをテストできます。ユニットテストのアプローチの手荷物から自分自身を解放したら、創造性の十分な余地があると言えば十分です。

于 2012-03-15T21:00:38.277 に答える
2

単体テストが可能なクラスのコードの大部分を分離することを試みることができます。

ここでの主な問題は、エンジンとパッケージが密閉されているため、簡単にモックアップできないことだと思います。ただし、これらのオブジェクトとの相互作用を最小限に抑え、関連する入力を受け取り、パッケージなどに配置する必要のある出力を返すクラスにコードの要点を配置することができます。

このアプローチを使用した単体テストだけで、TBBの多くのカバレッジを取得できると思います。

于 2012-03-15T13:31:45.013 に答える
2

2 つの目標を持つ独自の TestRunner を作成することをお勧めします: テスト データを作成し、テストを実行します。

テスト データの作成: アイデアは、サンプル データセットを作成することです (すべてのフィールド、一部のフィールド、および必須フィールドのみを自動的に)。(lorem ipsum の代わりに Chuck Norris の引用を使用することによるボーナス ポイント)。サンプル コンテンツのタイトルは、[TestContent] のような命名スキームを使用するか、メタデータが添付された独自のフォルダーにあります (後で見つけるため)。

テスト ページの作成: TestContent を見つけます。GetListUsingItems を使用して、テンプレートが使用されているページを見つけます。ページをコピーし、TestContent StructureGroup に貼り付けて保存します。ページを開き、テスト コンテンツを追加し、他のコンテンツを削除して、特別な名前付けスキーマでページを保存します。

テストの実行: TestContent を見つけて、それぞれをプレビューし、レンダリング時間、成功ステータス、および文字数を含むレポートを書き出します。

于 2012-03-15T14:39:54.060 に答える
2

CoreService シナリオの経験があります。テンプレートをアップロードし、複合テンプレートを作成して実行するには、いくつかのヘルパーを作成する必要があります。ただし、難しいのは検証です。

検証に役立ついくつかのテスト テンプレートを作成する必要があります。1 つの方法は、期待値を渡す .Net テンプレートを作成することです。これにより、検証が行われます。もう 1 つの方法は、パッケージから値を出力する DreamWeaver テンプレートを記述し、それを期待値と比較してチェックすることです。この方法の利点は、これらの値が CoreService Render アクションの結果として返され、クライアント側ですべての検証を実行できることです。

しかし、最も難しい部分はデータセットの作成です。おそらく、ほとんどの時間がかかります。

于 2012-03-15T13:26:34.610 に答える
2

ある顧客で、テストが Template Builder が使用するのと同じ Web サービスを呼び出し、これらを使用してテンプレートを実行し、結果を評価するなどの実装を見たことがあります。

おそらく探索する価値があります。

于 2012-03-15T14:34:04.593 に答える
1

あなたが使用するアプローチに関係なく、あなたの問題は完全に技術にとらわれないと考えています（Tridionのコンテキストで考える）。

問題は、複数の場所 (コンポーネント/ページ テンプレート) で使用されている 1 つのものを変更しており、有効な変更としてプッシュする前にそれらの場所をテストする必要があることです。

適切な変更を行ったとしても、コードが正常に実行され、結果が得られたと仮定すると、出力を使用する他の TBB が期待する結果ではない可能性があります。

残念ながら、それ自体が問題です:(問題がそのTBBを使用してすべてのテンプレートをテストする必要があることである場合、それはまだ解決策のない問題です。問題が現在のプラットフォームに影響を与えたくないということである場合変更/テストを行ったり、進行中の他の開発に干渉したりすることは、別のシナリオです。

テストする有効なコード/データを使用してパブリケーションを継承する別のパブリケーションを作成し (または事前に作成しておいて)、そこで変更を加えてテストすることで、2 つ目の問題を解決します。多くのコンポーネント/ページ テンプレートの一部として TBB を使用している場合、このアプローチは理にかなっています。

フロントエンドの粒度に余裕がある場合 (tbb がアトミックなコードを生成する場合)、シナリオの複雑さはわずかに軽減されますが、とにかくすべてのシナリオをテストする必要があります。

于 2012-03-30T02:21:19.627 に答える