問題タブ [acceptance-testing]

チャットクライアント（msnメッセンジャースタイル）を作成していますが、送信/受信機能の受け入れテストの作成に問題があります。

たとえば、「ユーザーは別のユーザーにメッセージを送信できる」というユーザーストーリーを考えてみてください。

1-クライアントswがサーバーと正しく対話するかどうかをテストする必要がありますか？この場合、この相互作用をどのように表現する必要がありますか？

2- 2番目のクライアントが実際にメッセージを受信するかどうかをテストする必要がありますか？この場合、ソフトウェアが正常に機能していることを証明するためにサーバーに依存する必要があります。この種の仮定は、検収試験で正しいですか？

私は自分のテストをコンコーディオンまたはフィットネスで書きたいのですが、すべての助けに本当に感謝しています。

ありがとうございました

このような長いチェーンを持ち、Then / Whenが混ざり合うユーザーストーリー/受け入れテストをどのように処理しますか？これを別の受け入れテストに分割して、1つはダイアログが表示されることをテストし、もう1つはダイアログが表示された後の動作をテストするのが最善ですか？

完全なエンド ツー エンド テストで、2 つ以上の Java クライアント間の相互作用をテストする必要があります。

GUI がなければ、理想的には (Junit 構文) のようなものにする必要があります。

上記のコードは、「アプリ」を同じ VM で実行するため、私が望むものではありません。

私が自分で考えることができた解決策は、secondApps をインスタンス化し、そのすべての出力をファイルに書き込む偽のメインを作成し、システム コールで起動して結果を確認することでしたが、それは本当にやり過ぎのようです。さらに、そのような戦略では、GUI もテストするのが (不可能ではないにしても) 難しくなります。

ご協力ありがとうございました。

だから私はステーキを使い始めました。ステーキはカピバラを使い、カピバラはセレンを使います。

したがって、テストを多くの小さなit句に分割し、それぞれが小さな機能をテストすることは、RSpecの優れた方法であると聞いています。ただし、テストごとに同じ手順が繰り返されるため、テストの実行にかかる時間が大幅に長くなります。

いくつかのajax機能をテストしているとしましょう。私はそれをテストしたい：

• 特定のリンクをクリックするとフォームが表示されます
• そのフォームに無効な入力を送信すると、エラーメッセージが表示されます
• 有効な入力などを送信すると、確認メッセージが表示されます。

しかし、これらのそれぞれを独自のテストケースに分割した場合、Seleniumは最初からやり直す必要があります。同じページを3回ロードし、リンクをクリックしてフォームを3回表示する必要があります。無駄。

私ができるようにしたいのは、ブラウザーの状態を保持する一連のテストを指定することです。これにより、各テストは前のテストが中断したところから続行されます。それは可能ですか？

別のフォームを送信する前に ajax 呼び出しを行うボタン (送信ボタンではない) があります。

私がやりたいことは

しかし、リダイレクトはやや遅れて発生し、ページがまだホームページにあることを考えると、「Then」ステートメントは失敗します。ajax 呼び出し (ボタンをクリックした結果) が終了し、ページがサブミッターになるまで待つにはどうすればよいですか??

何か案は？

編集: サンプル JavaScript コード

為に

Javascriptは（構文エラーを無視してください。全体的なアイデアが得られると思います）

私は現在、これから行うプログラムの設計を推進するのに役立ついくつかの受け入れテストを行っています。Acceptance-Tests が少し複雑であることに気付いたことを除けば、すべて問題ないように思えます。つまり、概念的には単純ですが、実行するにはかなりトリッキーなコードが必要です。受け入れテスト用にいくつかの「ヘルパー」クラスを作成する必要があります。

私の質問は、それらを開発する方法です。

1. 私の受け入れテストの単体テストを作成します（これは奇妙に思えます-誰かがそのようなことをしましたか？）
2. これらのヘルプ クラスの単体テストを作成します。これらのヘルプ クラスのすべてのコードを実行したら、システムの実際の単体テストに合格して作業を開始できます。このアプローチを使用する場合、ヘルパー クラスはどこに配置しますか? テストのプロジェクトまたは実際のプロジェクトで? それらは必ずしもテスト/モック フレームワークに依存しているわけではありません。
3. 他のアイデアはありますか？

私は現在、ウェブサイトを維持するために多くの頭痛の種を抱えています。ほとんどの場合、数回の更新後に問題が発生します。このウェブサイトは、私たちのチームの 2 人の開発者によって開始され、その後私に引き継がれました。プロジェクトが中途半端なのを考えると、単体テストと受け入れテストを行ってもよいかどうか疑問に思っていました。

今テストを書くのに長い時間がかかりますか? それは実用的でしょうか、それとも他のテスト方法はありますか?

私と同僚は議論をしています。私たちはひどいレガシープロジェクトに取り組んでおり、受け入れテストを徐々に追加しています。彼は、私たちがgui / watinで作業を行い、次に低レベルのライブラリを使用してデータベースに直接クエリを実行し、「エンドツーエンド」テストを取得する必要があると考えています。

私たちはNHibernateを使用しており、受け入れテストでアサーションを実行するためにgui/watinを使用してからそれらのnhibernateオブジェクトを使用することを推奨しています。彼はテストでのNHibernateの依存を嫌います。私の主張は、NHibernateオブジェクトに対して統合テストを実行して、意図したとおりにDBで動作していることを確認する必要があるというものでした。その時点で、適切な動作をアサートするための受け入れテストでそれらを使用することにマイナス面はありません。また、彼の低レベルのSQL依存性により、テストが脆弱になり、多くの場合、ビジネスロジックが重複すると思います。

当店での統合テストとは、基本的に、fileRepository / FileSystem Domain-NhibernateObject/Databaseなどの依存関係を持つ単一のコンポーネントを意味します。受け入れテストとは、GUIを介して参加することを意味します。ユニットとは、すべての依存関係がモックアウト/スタブアウトされ、メモリ内に純粋なテストがあり、テスト対象のメソッドのみが実際に実際の作業を実行していることを意味します。デフがオフになっているかどうか教えてください。

とにかく、あなたが私に指摘することができるこの主題についての意見を持つどんな記事/ドキュメント/羊皮紙もいただければ幸いです。

SpecFlowの例を見ていますが、MVCサンプルにはテスト用のいくつかの選択肢が含まれています。

• コントローラによって生成された検証結果に基づく受け入れテスト。
• MvcIntegrationTestFrameworkを使用した統合テスト。
• Seleniumを使用した自動受け入れテスト。
• テスターが結果を手動で検証するように求められた場合の手動受け入れテスト。

私はSpecFlowの例がどれほどうまく書かれているかに非常に感銘を受けていると言わなければなりません（そしてダウンロード後数分以内にそれらを実行することができ、データベースを構成してSelenium Remote Controlサーバーをインストールする必要がありました）。テストの代替案を見ると、それらのほとんどが代替案ではなく、互いに補完し合っていることがわかります。これらのテストの次の組み合わせを考えることができます。

• コントローラは、SpecFlowを使用するのではなく、TDDスタイルでテストされます（Given / When / Thenタイプのテストは、より高いエンドツーエンドレベルで適用する必要があります。それぞれのコンポーネントに適切なコードカバレッジを提供する必要があります。
• MvcIntegrationTestFrameworkは、開発セッション中に統合テストを実行するときに役立ちます。これらのテストもデイリービルドの一部です。
• Seleniumベースのテストは自動化されていますが、速度が遅く、主にQAセッション中に開始され、ページやサイトのワークフローに壊れたロジックがないことをすばやく検証します。
• テスターが結果の妥当性を確認するように求められたときの手動受け入れテストは、主にページのルックアンドフィールを確認することです。

Web開発でSpecFlow、Cucumber、またはその他のBDD受け入れテストフレームワークを使用している場合、さまざまなテストタイプからの選択に関する実践を共有してください。

前もって感謝します。

Rails Webアプリの統合テストには、Steak（Cucumberなど）を使用します。Steakのスペックは、spec/acceptanceという名前のフォルダーにあります。ステーキ/キュウリは現在、統合または受け入れテストのために使用されていますか？これは違うといつも思っていました。