3

sharepoint で開発されたアプリに CodedUI テストを使用しています。問題は、異なる環境で機能しないことです。そのため、面倒でエラーが発生しやすい環境ごとにテストを再記録する必要があります。

少し調べてみると、サーバー コントロール用に生成された Web パーツの clientId は、環境ごとに異なることがわかりました (ページ内のすべてがまったく同じ (マスター ページ、ページ レイアウト、Web パーツ) であっても)。

この問題を (ほぼ) 回避するために、SearchPropertyExpressions を編集して、「contains」演算子で clientID の最後のセグメントのみを使用することを考えました。これは、生成されたコードを designer.cs で手動で編集する場合にうまく機能します。

私の質問は、これを自動化する簡単でエレガントな方法はありますか?

これまでに試したことは次のとおりです。インデクサー セッターの PropertyExpressionCollection クラスを独自の関数に置き換えました。この関数を使用して、設定されている値を確認し、文字列「ctl」で値を変更し、文字列の最後のセグメントに置き換えます (たとえば、「ctl0123_textbox1」を「textbox1」に置き換えます)。最後に、contains 演算子を使用します。それは正常に動作します。しかし、入力を無差別にフィルタリングします。フィルターか検索かは気にせず、どのタイプのコントロールに属しているかさえ知りません。この方法は確かにハックです。

4

1 に答える 1

2

現在、まったく同じ問題に直面しています (アプリの 20 のカスタマイズされたバージョンをサポートする必要があります)。私たちがたどり着いた一般的な解決策：

1) ビジネス ロジックからの抽象 UI インタラクション (XML ファイルから逆シリアル化する UITestControls 用のカスタム ファブリックがあります)

2) クライアントごとに、必要に応じて UI インタラクション ロジックを微調整し、開発者がアプリケーションを微調整するのとまったく同じ方法で分岐します。

3) したがって、アプリケーションのすべてのブランチ (「異なる環境」) に対して、ロジックは同じですが UI レイヤーは異なります。

4) これで、この環境での使用を意図した XML UI 表記ファイルをテストに渡して満足することができます。

このソリューションは難しく、複雑なコードが必要ですが、必要な柔軟性が得られます。そして、テストを記録するのではなく、ゼロから作成するので、コードはよりクリーンで保守しやすくなります。

お役に立てれば。必要に応じて、より詳細な情報を提供する場合があります。

于 2011-09-02T15:29:03.203 に答える