SenchaアプリケーションのUIテスト

5907 ワード

原文:http://www.sencha.com/blog/ui-testing-a-sencha-app/
数ヶ月前、筆者は「自動化ユニットテスト」というテーマの文章を書きました.開発者が業務ロジックのためにユニットテストを行い、Javascript文法を検証することに関連しています.企業のアプリケーションを作成するには、これらの概念を理解する必要があります:製品にアップデートする前にエラーをキャプチャする必要があります.
その文章では扱っていない分野の一つが「UIテスト(統合テストとも呼ばれる、Integration Testing)」という観念です.その記事について多くのコメントを読んでコミュニティのフィードバックを聞いた後、私はExtJSアプリケーションにUIテストを追加し、企業のアプリケーションテスト戦略を議論する文章を発表することにしました.
UIテスト:概要
前に述べたように、UIテストとユニットテストは同じものではないので、この2つの概念はしばしば困惑します.
UIテストは、静的(平面レンダリング)および動的(ユーザ操作によって与えられた挙動)の両方を含む、画面上の要素挙動を主観的に検証することである.セルテストは、小さいサイズのコードに対して、応用ロジックを客観的に検証します.
それらの主な違いは、性質をテストする主観と客観性にある.
この観念はさらに、UIテストを2つの構成部分に分割することができる.QAテストとコンポーネントテスト.

QAテストシミュレーションは、ユーザがアプリケーションを使用する際に、現実世界とアプリケーションの相互作用をテストするものである.

コンポーネントテストは、アプリケーションを異なるブロックに分割して表示と動作を検証することである.

本論文では、これらの2つのタイプのUIテストが見られます.
UIテストを使うよくある問題
正しいツールを選択
テストアプリケーションの外観と複雑なインタラクションは困難な任務であるため、多くのWeb開発者がUIテストによってQA問題を十分に解決することを抵抗しているのも不思議ではない.
実は、開発者が解決しなければならない最大の障害はこの仕事のために一番いいものを選ぶことです.いくつかのツールは、XpathまたはCSSセレクタに依存してアプリケーションをブラウズし、また、自動化テストを実現するために複雑なサーバ構成が必要である.結局、弾力性に富んだツールを選ぶことは非常に重要であり、QAテストは業務の需要によって、あるいはアプリケーションの修正によって頻繁に書き換えられます.
筆者の経験では、SenchaアプリケーションのQAテストを作成するのに適した3つのツールがあります.

Selenium

CasperJS(PhotomJSプラットフォームで実行したい)

Siesta

これらのツールはどれも優れた利点と欠点がありますが、個人的にはSiestaの方が配置しやすいと思います.そしてAPIはSenchaのフレームワークとシームレスに作業できます.
免責声明:他のUIテストツールは、彼らを使うことを主張しません.Siestaが現在の最も「良い」ツールであることを主張しません.私はただ自分の経験に基づいて意見を提供します.
アナログデータ
UIテストを使用するもう一つの重要な問題(常に無視される)は、テストはオンラインAPIのために作成されたものではないことである.どんな理由であれ、API自体は信頼できない:サーバーあたご、ネットワークの遅延、例外エラーなどが発生します.
UIテストの目的は、任意の所与の時間に存在する特定のデータではなく、表示と動作を検証することである.もし可能であれば、UIテストはAPIデータをシミュレートしなければならないが、これは解決しやすい問題ではない.いくつかのインプリメンテーションは、Ajax要求の静的データを使用し、他のいくつかは、APIをシミュレートするためにリダイレクトネットワークを調整する必要がある.
Javascriptアナログライブラリだけではなく、コントロールしにくい問題がありますが、この問題を本文で深く検討するつもりはありません.私はただ皆さんにこの問題についての認識を提供したいです.それはしばしば人を落胆させます.例示的なアプリケーションでは、Sinon.jsはAPI呼び出しのためのメモリとして使用される.
こんなにたくさん話したら、オンラインAPIを使うべきだと思われるかもしれませんが、通常はリリースされたバージョンを検証する時だけオンラインのAPIを使うことを勧めます.
アプリケーションの例
例のExt JSアプリケーションでは、ui-testsフォルダでSiestaを用いて作成されたQAテスト(/app/)とコンポーネントテスト(/ux/)を見つけることができます.
QAテスト
ファイルの下で、ブラウザでindex.ファイルを開けてQAテストのSiestaインターフェースを確認することができます.ここでの目標は実際のアプリケーションを実行し、ユーザーが望む現実世界のインタラクションをテストすることです.例示的なアプリケーションは比較的簡単な例であるが、2つのQAテストは、テストアプリケーションのすべての動作の異なる方法を示している.
最初のテストは、「Testtabs for data in grids」という名前です.アプリケーションを簡単にロードして、要求されたビューの表示が正しいかどうかを確認します.この特殊な例は元のものと比較しても、アプリケーションがユーザの役割、好み、または他のいくつかの論理ダイナミックに基づいてインタフェースを作成する場合、テスト結果は非常に有用であるかもしれない.
二つ目のテストは「Testdouble-click functionlity」という名前で、アプリケーション全体を再読み込みします.今回はGridとラベルの相互作用をシミュレーションして、必要な行動が予想通りに実行されることを確認します.
なお、ここではStoreのJsonP要求の控えとしてSinon.jsファイルを使用しています.このようにすれば、オンラインAPIがアクセスでき、正常に動作すると仮定する必要はなく、アプリケーションの機能をテストすることができる.このようなことができる多くの方法があります.ここではExt.data.Json.request()を書き換える行為を選択して、自動的にアナログデータに戻ります.
コンポーネントテスト
ファイルの下で、コンポーネントテストのSiestaインターフェースをブラウザで開くことができます.QAテストとは違って、ここでの目標は各コンポーネントを分離し、彼らの行動をテストすることです.大きなアプリケーション以外のコンポーネントをテストすることで、既知のエラーを隔離し、将来の互換性を確保することができます.
例示的なアプリケーション(/app/tests/01 uRsvpWindow.js)の唯一のテストは、RsvpWindowビューの表示と動作を確認することである.デフォルトでは、ビュー(Windowクラスから拡張)は300で表示されます.×300のサイズ、タイトルをモダリティウィンドウとしてイジェクトする.Siestaを使用して、独立したビューインスタンスを作成し、これらのデフォルトのプロファイルを検証します.

   var defaultWin = Ext.create('ChicagoMeetup.view.RsvpWindow', {
       //default configs
   });
 
   t.is(defaultWin.modal, true, 'RsvpWindow should be modal.');
   t.is(defaultWin.title, 'RSVPs for the selected Meetup', 'RsvpWindow should have a title of "RSVPs for the selected Meetup".');
   t.is(defaultWin.getHeight(), 300, 'RsvpWindow should be 300px tall.');
   t.is(defaultWin.getWidth(), 300, 'RsvpWindow should be 300px wide.');
   t.is(defaultWin.getLayout().type, 'fit', 'RsvpWindow should have "fit" layout.');

これは非常に有用であり、また優れた注意であり、RsvpWindowがカスタマイズされることを再利用できるようにすることができます.Siestaテストでは、他のRsvpWindowの例も作成できますが、今回は初期化プロセスが成功するようにデフォルト値を書き換えます.

   var customWin = Ext.create('ChicagoMeetup.view.RsvpWindow', {
       modal  : false,
       title  : 'Foobar Window',
       height : 400,
       width  : 200,
       layout : 'card'
   });
 
   t.is(customWin.modal, false, 'RsvpWindow should be modal.');
   t.is(customWin.title, 'Foobar Window', 'RsvpWindow should have a title of "Foobar Window".');
   t.is(customWin.getHeight(), 400, 'RsvpWindow should be 300px tall.');
   t.is(customWin.getWidth(), 200, 'RsvpWindow should be 300px wide.');
   t.is(customWin.getLayout().type, 'card', 'RsvpWindow should have "card" layout.');

Siestaの強力なテストAPIを使用して、コンポーネントの様々なインタラクション方式(click、dragなど)をシミュレートすることができる.RsvpWindowコンポーネントはまだ興奮に足りないですが、それらのカスタムUX類の可能性を想像してみてください.
結論としては、Webさくらプログラムを作成するためのユニットテストは、困難なタスクかもしれないが、努力したときのリターンとしては、価値がありません.最後に、筆者はこれらのポイントを再確認したいと思います.

ユニットテストとUIテストは異なります.両者は安定したコードを維持することに価値がありますが、彼らは異なる問題を解決するために使います.

文法に注意する.コードが一つのブラウザで実行されるだけで正しいということは、ブラウザごとに正しい動作ができるということではない.

は、カスタムコンポーネントをテストする.フレームは予想通り正常に運行されましたが、UXは正しいと思わないでください.

は、コードの100%のカバー率を狙ってはいけません.アプリケーション全体をテストする考えがあるかもしれませんが、複雑なテストキットを維持するコストを考慮します.

このシリーズのセルテストに関する文章は筆者の個人的な経験に基づいてSenchaのユーザーに協力して共通の問題を解決するものです.ネットワークショップでもっと勉強になります.筆者は1月31日のMats Brynctsを主宰して、実際に即したテストExt JSとTouchアプリケーションの方法を開発者に紹介します.登録住所はここです.また、自分の考えと経験を共有するように招待します.お互いに助け合いながら、Webアプリケーションのテストをより簡単に目標を達成することができるようにしてください.
Athur Kay Arethur Kay has working with the Web since the late 1990 s,when GeoCites and scrolling markees were all the rage.Since those early days,Athur graduted Loyour University canceand has workd in a variety of professional roles throughot the Internet industry.Athur currently lives in the Chicago suburbs and works as a Solutions Entineer for Sencha,Inc.

JavaScript switch…caseにifなどの選択構造を入れ替えることができますか?