4

シェフがレシピを作成でき、スーシェフがヘッドシェフの承認が必要なレシピを作成できるとします。

ヘッドシェフが自分のホームページを表示すると、自分で作成したレシピが表示されることをテストします。また、承認を待っているレシピがあることを彼女が確認することをテストする必要があります。

これを行うには2つの方法が考えられます。

  1. ビューに「あなたのレシピ」や「承認待ちのレシピ」などの特定の単語が含まれていることをテストします
  2. 使用しているhtml要素に不要な属性を追加して、「id=recipe_1」または「data-for-the-sake-of-testing=1」の要素を確認できるようにします。

私はこれらのアプローチの両方が非常に嫌いです。

アプローチ＃1がダメな理由

  1. 信じられないほどもろいテスト。コピーにマイナーな更新を加えるたびに、テストは失敗します。
  2. i18n？それはこのアプローチでどのように機能しますか？

おそらくもっと多くの理由がありますが、これら2つはかなり巨大です。

アプローチ＃2がダメな理由

テストのためだけに余分なマークアップを付けるのは、なんと面倒なことでしょう。ユーザーは、テストのためにダウンロードサイズを大きくしないでください。

これへの良いアプローチは何ですか？私はあなたが考えるどんな言語でも、どんな代替案も聞くことに興味があります。私は主にRuby、Test :: Unit、Minitest、RSpec、Cucumberで考えます（私のCukeスキルは古くなっていますが）が、他の言語/フレームワークの場合これを理解して、私も彼らが何をしているのか見てみたいです。

4

4 に答える 4

4

ページ パラダイムを使用します。

可能な限り機能のレベル (高レベル) で、できる限り人間らしい方法でステップを表現し、具体的な例を使用します。たとえば、Cucumber を使用している場合、次のように言うかもしれません。

スーシェフがフロッグパイのレシピを作成したと
すると、シェフが承認するレシピを探すと、
フロッグパイのレシピがリストにあるはずです。

これらの手順のコード内で、探している特定のページをインスタンス化または検索します。ページは、ページの機能を表すオブジェクトです。そのページには、レシピの検索、レシピの承認、別のページへの移動など、ユーザーがページで実行できるすべての操作を含めることができます。

このように、ステップの基礎となるコードを変更する必要がある場合、1 か所で変更するだけで済み、特定のページのすべての変更がまとめられます。提供する機能の観点からシナリオを表現したため、シナリオを大幅に変更する必要はほとんどありません (提供する機能とは異なる機能がビジネスに必要であることが判明しない限り)。

これは、各ウィジェットまたはモジュールが特定のページであるウィンドウベースのアプリでも非常にうまく機能します。

テスト用に追加の ID を付けても問題ありません。時にはデザイナーもそれらを使用したいことがあります。

于 2012-05-21T08:28:51.547 に答える
4

少なくとも 2 つのオプションがあります。

  1. UI を使用してビジネス ロジックをテストすることは避けてください。プレーンなデータ構造を返す「サービス」または「ユース ケース コントローラー」オブジェクトを記述します。つまり、システムに API を構築します。単体テストは、API を介してシステムにアクセスします。UI は同じ API を介してシステムにアクセスしますが、ビューにはロジックがほとんどないはずです。http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-yearsまたはhttp://www.cleancoders.com/codecast/clean-code-episode-7/showを参照してください。

  2. 「ページ オブジェクト」パターンを使用します。アプリが生成する HTML コードを読み取り、それを解析して、getter を介して興味深いデータを利用できるようにするオブジェクトを作成します。これはあなたのテストを行うのに驚くべきことですコードクリア。あなたの異議は、問題 2 がまだ残っているということかもしれません。実際、それは本当に問題ではないと思います。構造的な HTML マークアップを使用すると、必要な情報を簡単に抽出できます。ページの重要な要素に ID を付けると、はるかに簡単になります。あなたの例では、id="my-recipes" を持つ div と id="to-be-approved" を持つ別の div があります。これで十分です。それ以外は、xpath または css セレクターを使用して簡単に見つけることができます。なぜこれを好ましくないと思うのですか？これらの ID は、目立たない JavaScript でビヘイビアーをアタッチしたり、CSS スタイルシートでスタイルをアタッチしたりするなど、他の目的に役立つ可能性があります。

于 2012-05-26T14:12:53.140 に答える
1

私は個人的にビューをまったくテストしないようにしています。これらのテストは非常に壊れやすいように見えるため、生成されたマークアップを意味します。

代わりに、MVC Web フレームワークがコントローラーの場合、「データプロバイダー」側に焦点を当てます。コントローラーが、どのような種類のデータ コントローラーが準備されているかを確認する単体テストによってカバーされるとすぐに、ほとんど安全になります。作成したビューは、アプリケーションを実行するだけで簡単にテストでき、問題がないことを確認できます。

それにもかかわらず、ビュー テストのいくつかのアプローチがあります。1 つ目は、Selenium ドライバーを使用した「エンドツーエンド」のテスト シミュレーションに基づいています。ブラウザーを実行し、アプリケーションへの要求を初期化します。テストは出力 HTML をチェックしています。テストは「既知の」エディションにログオンします。たとえば、現在のローカリゼーションが EN であることをテストが認識していることを意味します。

基本的にアプローチを組み合わせる必要があります。それが機能する場合は HTML マークアップ値 (「レシピ」) を使用し、それ以外の場合は HTML 要素の ID またはクラスを使用します。テスト用の追加のマークアップは追加しません。

試すことができる別のアプローチは、承認テストです。そのためのRubyドライバーがあると思います- http://approvaltests.sourceforge.net/。承認を得て、ビューをレンダリングし、HTML をゴールデン マスターとして保存します。ビューが変更された場合、テストは失敗します。Selenium テストよりもはるかに簡単に実装できます。

于 2012-05-21T06:43:57.223 に答える
1

おそらく簡単なコメントを使用して、＃2を使用します（i18nの問題はなく、エンドユーザーには表示されません）：

<!-- APPROVAL -->

simpletestのドキュメントには、次のような優れた内容があります。

次の機会は、回路基板、おそらく今見ているコンピュータのマザーボードを見てください。ほとんどのボードには、奇妙な空の穴、または何も取り付けられていないはんだ接合部、または明らかな機能のないピンまたはソケットが見られます。これらの一部は拡張とバリエーション用である可能性がありますが、残りのほとんどはテスト用です。

少量の余分なマークアップによって製品のテスト可能性と信頼性が向上する場合は、そのままにしておいてください。

于 2012-05-19T10:37:13.657 に答える