Visual Studio 2013のASP.NET MVCソリューションにコード化されたUIテストを追加しました。各ページは、テスト機器が起動し、フォームフィールドへの入力を開始するまでに、1分以上かかることがあります。
いくつかの実験(SmartMatch
をオフにすることを含む)の後、私は単に
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
問題を解決します。しかし、予想どおり、UIスレッドがテスト機械がフォーム上のコントロールと対話する準備ができていないため、テストは頻繁に失敗します。
呼び出す
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;
ゆっくりとした場合でも、テストを確実に実行します。
考えや提案はありますか?誰かがWaitForReady機構に組み込まれた魔法について何らかの洞察を得る可能性を望んでいますか? WaitForReadyLevel
以外にいじることができるWaitForReadyに関連する他の設定はありますか?
少し実験した後、コード化されたUIテストをフルスピードで確実に実行できる設定の組み合わせのように見えるものを見つけました。手動でWebサイトを操作するよりも高速です。
注:関連する「ドキュメント」(ブログを「ドキュメント」と呼ぶ場合)は、次の場所にあります。
このトリックでは、デフォルトの再生設定をいくつか変更する必要があります。
WaitForReadyLevel = WaitForReadyLevel.Disabled
を設定すると、テストをフルスピードで実行できます。ただし、ページ上のコントロールとの対話が安全になるまで待機する(遅い!)魔法も無効にします。
MaximumRetryCount
を設定し、エラーハンドラーをアタッチすると、「準備完了」マジックを無効にしたことによるエラーのほとんどが処理されます。 1秒Sleep
を再試行ロジックに焼き付けたので、この値は、ページが読み込まれて応答可能になるまで待機する秒数です。
明らかに、テスト中のコントロールを見つけることができないことは、エラーハンドラー/再試行メカニズムによって処理されるエラーの1つではありません。新しいページの読み込みに数秒以上かかり、新しいページが読み込まれるまで存在しないコントロールをテストが探している場合、テストはコントロールを見つけることができず、テストは失敗します。 ShouldSearchFailFast = false
を設定すると、ページをロードするための完全なタイムアウト時間が得られるので、この問題を解決できます。
DelayBetweenActions = 500
を設定すると、ページが読み込まれた直後に発生するボタンのクリックがUIで見落とされることがあるという問題を回避できるようです。テスト機械はボタンがクリックされたと考えているようですが、Webページはそれに応答しません。
「ドキュメント」によると、デフォルトの検索タイムアウトは3分ですが、実際には10分を超えるため、SearchTimeout
を明示的に1秒(1000ミリ秒)に設定しています。
すべてのコードを1か所に保管するために、すべてのテストで使用されるコードを含むクラスを作成しました。 MyCodedUITests.StartTest()
は、各テストクラスの[TestInitialize]
メソッドによって呼び出されます。
このコードは実際にはすべてのテストで(テストごとに1回ではなく)1回だけ実行する必要がありますが、Playback.PlaybackSettings
呼び出しを[AssemblyInitialization]
または[ClassInitialization]
ルーチンで機能させる方法を理解できませんでした。
/// <summary> A class containing Coded UI Tests. </summary>
[CodedUITest]
public class UI_Tests
{
/// <summary> Common initialization for all of the tests in this class. </summary>
[TestInitialize]
public void TestInit()
{
// Call a common routine to set up the test
MyCodedUITests.StartTest();
}
/// <summary> Some test. </summary>
[TestMethod]
public void SomeTest()
{
this.UIMap.Assert_HomePageElements();
this.UIMap.Recorded_DoSomething();
this.UIMap.Assert_FinalPageElements();
}
}
/// <summary> Coded UI Test support routines. </summary>
class MyCodedUITests
{
/// <summary> Test startup. </summary>
public static void StartTest()
{
// Configure the playback engine
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
Playback.PlaybackSettings.MaximumRetryCount = 10;
Playback.PlaybackSettings.ShouldSearchFailFast = false;
Playback.PlaybackSettings.DelayBetweenActions = 500;
Playback.PlaybackSettings.SearchTimeout = 1000;
// Add the error handler
Playback.PlaybackError -= Playback_PlaybackError; // Remove the handler if it's already added
Playback.PlaybackError += Playback_PlaybackError; // Ta dah...
}
/// <summary> PlaybackError event handler. </summary>
private static void Playback_PlaybackError(object sender, PlaybackErrorEventArgs e)
{
// Wait a second
System.Threading.Thread.Sleep(1000);
// Retry the failed test operation
e.Result = PlaybackErrorOptions.Retry;
}
}
コード化されたUIは画面上のコントロールを検索し、成功した場合、その検索は非常に高速です。ただし、検索が失敗した場合、コード化されたUIは「スマートマッチ」メソッドを使用してもう一度試行するため、遅くなる可能性があります。コード化されたUIがスマートマッチングの使用にフォールバックしないようにする基本的な方法は、実行ごとに変わる可能性のある検索項目を削除または簡略化することです。
このMicrosoftブログ は、何が発生し、それを修正する方法について多くの説明を提供します。この例では、検索文字列を次のように変更することで、30秒から8秒にスピードアップしています。
Name EqualsTo “Sales order (1 - ceu) - Sales order: SO-101375, Forest Wholesales”
に
Name Contains “Sales order (1 - ceu) - Sales order: SO”
Microsoftダイナミクスツールからキャプチャされたようです。検査ツールから取得した文字列の長さを確認してください。あなたはいくつかの隠されたキャラクターを見つけるでしょう。ただ注文(1-ceu)。または、カーソルを「(」から「)」に移動するだけです。右矢印キーを押してもカーソルが動かないことがあります。