TestCafe：機能テストで調和を見つける簡単な歴史（写真付き）

TestCafeは、 DevExpressが最近リリースしたクロスプラットフォームWebアプリケーション機能テストフレームワークです。



DevExpressでは、Web開発者向けのさまざまなコンポーネント（ ASP.NET WebForms 、 ASP.NET MVC 、およびJavaScriptコンポーネントとフレームワーク ）を開発しており、もちろんそれらをテストしています。 単体テストですべてが一般に明確であり、信じられないほどの啓示の余地がない場合、機能テストでは、実装の複雑さのために状況は明白です。 当初、TestCafeフレームワークは、コンポーネントおよびサイトの機能テストに関する差し迫った問題を解決することを目的とした内部開発でした。 そして、この内部開発が最終的に独立した製品に成長したことはたまたま起こりました。



この記事では、このフレームワークを作成するための前提条件、既存のソリューションでテストする際に発生した問題（ 致命的な欠陥を除く ）、およびそれらに対処する方法について説明します。

緊急について

問題：

既存のテストソリューションでは、問題はブラウザプラグインをインストールする必要があることです。 テスト環境のセットアップは非常に簡単になります-プラグインをブラウザにインストールする必要があります。ブラウザ自体を設定する必要がある場合があり、ブラウザの新しいバージョンのプラグインが機能しない場合がありますが、ここでテストする必要があります。



多くの場合、大規模な開発チームでは、すべての開発者が単にテスト環境をインストールしたり、古いバージョンのテストフレームワークをインストールしたりするわけではありません。 そして、継続的な統合システムではテストがクラッシュし、エラーを早急に修正する必要があり、同時にテストのローカルでの「開始」のためだけに時間の大部分が費やされるという状況が発生します。 継続的インテグレーションシステムのフレームワークであるプラグインの更新は、別の楽しいトピックです。



また、ここではモバイルデバイスを独立させています。 ほとんどの構成では、プラグインはありません。プラグインをインストールするのは簡単ではありません。

TestCafeの主な「機能」は、フレームワークがブラウザープラグインまたはブラウザーの事前設定を必要としないことです。 TestCafeは、ブラウザにプラグアンドプレイアプローチを使用します。 これを確認するには、現在この記事を表示しているブラウザーでデモテストを実行します。 ローカルマシンで作業している場合、TestCafeはインストールされたブラウザを自動的に検出し、ワーカーを作成します。







モバイルデバイスのブラウザから1つのボタンを押すか、QRコードをスキャンするだけで、モバイルデバイスを接続できます。







制御システム全体がWebベースのインターフェースを備えていることを別に言及する価値があります。 つまり ブラウザーをフレームワークに接続するだけで、同僚のマシンでテストを実行し、その結果を分析できます（同じネットワーク上にいる場合）。 この場合、同僚は何もインストールする必要はありません。 さらに、この柔軟性により、 ブラウザスタック仮想マシンなどの任意のリモート環境でテストを実行できます 。



また、TestCafeはブラウザーとキーボード/マウス入力をブロックしません。 つまり お気に入りのブラウザの別のタブで作業を続けながら、所有するすべてのブラウザで並行してテストを実行できます。



問題：

テストコードと製品コードには大きな違いが1つあります。原則として、テストは一度書かれたコードですが、開発されたアプリケーションの作業における違反を分析するためにこのコードに戻ることがよくあります。 つまり テストコードの主な目的は問題を特定することなので、次の2つの要件があります。

• テストシナリオの決定性-テストは1つのアクションシナリオを正確に実行する必要があり、このシナリオはテストコードから簡単に理解できる必要があります。
• 問題が発生したシナリオのステージを迅速にローカライズする機能。

これらの考慮事項は、ある日同僚と私が非常に複雑な機能テストをデバッグしたときに、私の頭に強く刻み込まれました。 これはコードの壁であり、テストシナリオで何が起こっているのかを理解することは困難でした。 そのため、テストを段階的にデバッグし、目に見えるアクションをコードと比較しました。 どのシナリオを扱っているのかを理解するのに30分しかかかりませんでした！



はい、ここでの問題は主に人的要因です-テストは不器用に書かれており、テストを作成した人はその結果を分析する人の面倒を見ませんでした。 しかし、何をすべきか- 「人が足で自分を撃つことができる場合、遅かれ早かれ彼は足で自分を撃ちます。 」

しかし、以来 すべての人々を修正することは、やや実現可能で、少しだけ実行可能なタスクです。そして、TestCafeでは、困難な状況での行動の普遍的なアルゴリズムを適用しませんでした^[1] 。 このテストの結果を後で分析する人のために、テスト開発者の時間を少し犠牲にして（テストは通常​​1回書かれていることを思い出してください）、少し異なるパスを取りました。



TestCafeのテストはステップに分けられます。

'@fixture Example'; '@page http://testcafe.devexpress.com/Example'; '@test'['Drag slider'] = { '1.Click label "I have tried TestCafe"': function () { act.click(':containsExcludeChildren(I have tried TestCafe)'); }, '2.Check initial slider value': function() { eq($('#Developer_Rating').val(), 0); }, '3.Drag slider handle': function () { act.drag('.ui-slider-handle', 360, 0); }, '4.Check resulting slider value': function() { eq($('#Developer_Rating').val(), 7); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステップには2つの要件があります。

• ステップには名前を付ける必要があります。 開発者は何が起こっているのかを自然言語で説明する必要があります。
• 各ステップに含まれるユーザーアクションは1つのみです。

このアプローチは、開発者とテスターの間で最も混同されているとすぐに言います。 彼らはコードを書きたかったが、テキストを書かなければならなかった。 しかし、すぐに怒りがなくなり、開発者は同様のスタイルに慣れました。 しかし、今では十分に文書化され構造化されたテストがあり、開発者はより意味のあるテストコードを作成します。 以前は、自然言語で行動を定式化していました。 問題が発生した場合、コードの詳細な分析は不要になり、実装の詳細に入らずにテストの本質を簡単に読み取ることができます。



TestCafeがネットワークトラフィックとJavaScriptエラーを分析することも注目に値します。 また、テストがクラッシュした場合（アサーションがパスしなかった、または他のエラーが発生した場合）、フレームワークはクラッシュの考えられる原因-アンロードされたリソースまたはコード内のエラーを示します。



問題：

機能テストは簡単に思えます。特定のシナリオでエンドユーザーのアクションをエミュレートし、結果を評価します。 しかし、ユーザーの制御外で発生するが、スクリプトの実行に影響する多くの隠されたメカニズムがあります。 そして、テスト開発者はそれらを考慮する必要があります。



たとえば、ボタンを押すと、非同期XHRリクエストが送信され、一部のデータが応答し、そこからページブロックが構築され、ユーザーに表示されます。 ユーザーにとっては、これはほんのわずかな視覚的な遅延ですが、マシンにとっては、副作用と非決定的な完了時間を伴うアクションです。 そして、起こっていることの意味を深めることなく、良いテストを書くことは難しいことがわかります（結局、テストでは、XHRリクエストが完了するまで待ってから次のステップに進む必要があることを明確に示す必要があります）。 内部メカニズムがテストの合格に強い影響を与える場合、他のオプションがあります。 たとえば、多くのフレームワークでは、テストを実行する前に手動でCookieをクリアする必要があります。 このようなクリーニングを行うことを忘れて、非常に不安定でデバッグが困難なテストを受けることができます。

前述のテストステップメカニズムを覚えていますか？ コードの構造を改善することに加えて、別の問題も解決します-アプリケーションの状態間の遷移を平準化することができます。 つまり TestCafeは、 waitForPageLoad（）やwaitForXhrComplete（）などを明示的に規定する必要はありません。 なぜなら 各ステップにはアクションが1つだけ含まれているため、TestCafeはページ間の遷移の完了と、このアクションによって引き起こされるXHRリクエストの終了を自動的に予測します。 したがって、テストで過渡状態を記述する必要はありません。 テストには、ユーザーアクションのエミュレーションと、ユーザーが導く最終状態の分析のみが含まれます。



また、 Cookieのクリアも行いました。 各テストは、基本的にテストコンテナーで実行され、テストの開始時には常に空のCookieが含まれています。 状態をリセットしたり、ブラウザのテスト環境をセットアップしたりする必要はありません。 これは自動的に行われます。



問題：

多くの場合、テスト済みのページには基本認証またはWindows認証が必要です。 多くの場合、この問題には「すぐに使える」解決策がありません。

TestCafeには、これらの認証プロトコルのサポートが組み込まれています-ログイン情報を入力するだけで、ブラウザと同様にTestCafeが自動的に認証されます。







テストコードでログイン情報を指定することもできます。

 '@auth guest:MostlyHarmless'; '@test'['Click Input'] = { '1. Type name': function() { act.type(getInput(), 'Peter Parker'); }, '2. Move caret position': function() { act.click(getInput(), { caretPos: 5 }); }, '3. Erase a character': function() { act.press('backspace'); }, '4. Check result': function() { eq(getInput().val(), 'Pete Parker'); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題：

機能テストフレームワークAPI-特に注目に値するもの。 DOM上のこれらの巨大なアドオンは、ブラウザーのDOM APIの革新に追いついていない場合がありますが、学ぶのが最も簡単なものではありません。



「しかし、DOMとJavaScriptに慣れていないテスターに​​とっては簡単です！」とあなたは言います。 ただし、このステートメントには内部的な矛盾が含まれています。このAPIは、いずれにしてもネイティブDOMツリーのラッパーです。 つまり いずれの場合でも、DOMの構造を理解し、さらに追加のAPIを念頭に置いて、一方が他方に投影される方法を理解する必要があります。

既にお気づきかもしれませんが、TestCafeでテストを作成するための言語はJavaScriptです。 正確には、これはDSLであり、JavaScriptのサブセットです。 つまり、既存のJavaScriptエディターは、構文の強調表示、オートコンプリート、リファクタリングなど、付随するすべての「便利な機能」を備えたテストファイルを簡単に開くことができます。



さらに、ウェブにはJavaScriptほど自然な言語はありません。 TestCafeには中間APIはありません。DOMを直接操作できます（Vanilla JSの大ファンの場合）。または、jQueryの自動接続バージョンを使用できます。



TestCafeで利用可能なエンドユーザーエミュレーションには特別な注意を払う必要があります。 APIを可能な限り最小限に抑えながら、可能な限り柔軟性を維持しようとしました。 メソッドは11個しかありませんが、実際に遭遇したほとんどすべてのシナリオをカバーしています。



TestCafe APIには、オブジェクトタイプを認識して「詳細な」比較を行うことができる4つのタイプのアサーションも含まれています。 テストを編集するには、フレームワークに組み込まれたエディターを使用できます。







お気に入りのJavaScriptエディターを使用することもできます。 TestCafeはテストをオンザフライでコンパイルします。そのため、構文エラーを犯したり、テスト構造を誤って作成した場合、すぐに通知されます。







問題：

機能テストは不安定になる可能性があります。 原則として、その理由は、ユーザーのアクションからエフェクトが終了するまでの待ち時間が誤って設定されているためです。 時間間隔の変更は、ネットワーク遅延、コンピューターの低速、テスト対象のアプリケーションの低速など、多くの要因によって引き起こされる可能性があります。 前述のように、TestCafeには、ページの移行とXHRリクエストの終了を待機するメカニズムが組み込まれています。 ただし、アニメーションの期待値のヒューリスティックはまだ研究段階であり、フレームワークのリリースブランチには含まれていません。 さらに、テストの不安定性は、テスト対象のアプリケーション自体の不安定性によって引き起こされる可能性があります。

このようなテストをキャッチするために、TestCafeは特別なモードであるQuarantine Modeを導入しました。これは一般に、Martin Fowlerの不安定なテストの隔離に関するアイデアの技術的な実装です 。 その本質は非常に単純です。テストがクラッシュした場合、それはすぐに落ちたテストのリストに追加されるのではなく、隔離されます。 これは、テストがさらに2回実行され、合格の結果が異なる場合、そのようなテストがレポートの不安定なテストのリストに追加されることを意味します。



このかなり単純なメカニズムにより、非決定的な結果を持つテストを効果的にキャッチできます。 統計的サンプルの量がもちろんはるかに大きい連続積分システムで作業する場合、特に良い結果が得られます。 ところで、TestCafeには継続的な統合のための組み込みAPIがあります 。 フレームワークは、 npmを介して通常のノードライブラリとして利用できます。

テストレコーダーについて

もちろん、前述のすべてに加えて、TestCafeには、セレクターの便利なライブエディターと実行されたアクションをロールバックする機能を備えた組み込みのテストレコーダーがあります。

結論として

TestCafeを開発する際、膨大な数のオープンソース開発を使用したため、オープンソースコミュニティを信用しないのは少し不公平です。 そのため、TestCafe開発のコンテキストでは、parse5が作成されました。これは、node.jsのHTML5仕様と完全に互換性のある最速のパーサーであるHTMLパーサー^[2]です。 また、 whackoは、parse5をプラットフォームとして使用するcheerioライブラリのフォークです。



私たちはまだ将来の膨大な数の計画を持っています、それをできるだけ早く実装しようとしています（TestCafeメジャーリリースは約2か月ごとに出ています）。 将来的には、ユーザビリティと速度の明らかな改善に加えて、より多くのユニークで興味深い機能が私たちを待っています。 連絡を取り合いましょう！

注釈