14

よくある話

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

このように広い範囲をカバーしているので、DBなどのシステムコンポーネントをモックしてテストを行うのは無意味ですが、統合テストでは主にBDDを使用していると言えますか？

4

4 に答える 4

17

これが私の用語です。

  • シナリオ：システムを使用しているユーザーの例。関連するすべてのコンポーネントがモックアウトされているのではなく、配置されています。自動化され、受け入れテストとして使用される場合がありますが、ビジネス、テスター、および開発者間の会話は、BDDの最も重要な側面です。多くの場合、Given / When / Thenテンプレートを使用して作成されますが、 CucumberやJBehaveなどの自然言語キャプチャを可能にするツールで作成されることもあります。

  • 統合テスト： 2つのコンポーネントの境界を越え、通常、これらのコンポーネントの統合の整合性をチェックするために使用されます。たとえば、Webインターフェイスのクライアント層とサーバー層の間でメッセージを送受信したり、Hibernateなどとのデータベースバインディングをチェックしたりするために使用できます。必ずしもフルスタックが含まれるとは限りません。シナリオは、特定の種類の統合テストと見なすことができます。BDDは、ほとんどの非シナリオ統合テストには実際には適用されませんが、Given / When/Thenテンプレートを使用することは考えられます。

  • 単体テスト：通常は共同作業者がモックアウトされた、別のクラスを使用する消費クラスの例。また、消費クラスのデリゲートがその共同作業者にどのように機能するかの例でもあります。とにかく、それがBDDでの話し方です（両方のレベルでBDDを実行できます）。また、Given / When/Then構文を使用できます。

  • ストーリー：より迅速なフィードバックを得ることができるようにするための機能のスライス。機能の動作はいくつかのシナリオで説明できますが、これらを使用して機能を細かく分割することもできます。多くの場合、As a ... I want ... So that ... template、またはIn to ... as a ... I want ... template ofFeatureInjectionで示されます。

  • 機能：機能は、ユーザーが提供する機能を使用する方法を表します。これは、具体的な実装とUIの定義を開始する段階です。機能には、Webページ、Webページの一部、Windows UIのモジュール、アプリの一部などがあります。

  • 機能：ユーザーがシステムで達成できること、またはシステムが達成できること。すなわち：ユーザーは取引を予約することができ、システムはハッカーに耐えるのに十分安全です。このレベルのフレーズシナリオは、UIから独立し、ビジネスの言語でシナリオを維持するのに役立ちます。

お役に立てれば。

于 2012-08-21T15:11:27.343 に答える
9

あなたの例は、受け入れテストを説明するユーザーストーリーです。受け入れテストはエンドツーエンドの範囲を持つことができますが、必ずしもそうとは限りません。受け入れテストと統合テストの主な違いは、それらが何に焦点を当てているかです。受け入れテストはビジネスに焦点を当てたものであり、技術者ではない人 (顧客) が書いたり読んだりすることができます。一方、開発に重点を置いた統合テストがあります。これは、2 つ以上のコンポーネントが連携できることを単純に検証するものです。

BDDに戻ります。受け入れテスト (機能レベル) および単体テスト (コード レベル) で使用できます。さまざまなレベルの BDD に対応するさまざまなツールもあります。

  • SpecFlow (受け入れテスト)
  • NSpec、NBehave (単体テスト)
于 2012-08-20T21:49:09.470 に答える
3

動作駆動開発は、特定のシナリオでの製品の動作について考えています。テスト駆動開発とドメイン駆動設計の両方を拡張します。また、BDD は統合テストを超えて考えています。BDD は、ユーザー、開発者、テスター、マネージャー、およびアナリスト間のコミュニケーションを最大化することを目的としています。

統合テストは、BDD の 1 ステップと見なされます。統合テストは、BDD のコンテキスト外に存在することもあります。統合テストを使用すると、単体テストに陥ることなく、アプリケーションの高レベルの動作をカバーできます。

動作はシステムのコンポーネント間の相互作用に関するものであるため、モッキングの使用は高度な TDD の基本です。TDD の専門知識は、TDD がテストではなく動作を定義することであることに開発者が気付く時点で始まります。

ユーザー ストーリーは、人間に優しいソフトウェアを開発する上で常に優先事項であるため、幅広い範囲を持つ場合があります。エクストリーム プログラミングの実用的なアプローチと、マクロ レベル分析に基づく十分な事前思考を組み合わせて、マクロ レベル プランニングを可能にします。

于 2012-08-21T07:07:28.123 に答える
2

統合テストは、主にBDDを使用しているものです-Seleniumを使用したUIテスト。実際には、BDD シナリオを使用して SpecFlow を駆動し、Selenium Webdriver を駆動して、ログイン、メニュー リンクのクリック、レコードの作成などのユーザー ジャーニーを実行するため、これらのテストで何もモックしていません。実際、私はできる限り UI を介してすべてを行うように最善を尽くしています。

私は、ビジネス アナリストと協力して BDD 方式でユーザー ストーリーを作成してきました (実際、クライアントとの契約に含まれています)。BDD でストーリーを作成しているときに、それを見つけるのは非常に新鮮で役に立ちました。要件をアトミックなステップ (Given、When、Then) に外挿すると、他の方法では考えられなかった可能性のあるエッジ ケースが見つかります。要件を表現するためのより一般的な言語があれば、ビジネスと開発者の両方の視点にとって、まさにウィンウィンのシナリオです。

于 2012-08-22T13:50:26.177 に答える