問題タブ [atdd]

彼の記事What's in a Story? で ダン・ノースは多くの優れた点を挙げています。特に次の 3 つです。

1. シナリオのタイトルは、何が違うのかを示す必要があります

   シナリオを並べて並べ、タイトルのみを使用してそれらの違いを説明できる必要があります。

2. シナリオは、ギブンス、イベント、および結果の観点から説明する必要があります

   これは、BDD を採用しているチームで私が見た最も強力な行動の変化です。ビジネス ユーザー、アナリスト、テスター、および開発者に、この「与えられた/いつ/その時」という語彙を採用させるだけで、あいまいな世界がなくなることがわかります。

   すべてのシナリオがこれほど単純なわけではありません。いくつかは一連の出来事として表現するのが最もよく、次のように表現されます: [ある文脈] が与えられたとき [私が何かをする] のとき [これが起こる] [私が別のことをする] のとき [この新しいことが起こる]など。例として、一連の画面をステップ実行して複雑なデータ モデルを構築するウィザード スタイルの Web サイトがあります。これらの用語で考える習慣を身につけている限り、一連の出来事と結果を混ぜ合わせることは完全に適切です.

3. ストーリーは、イテレーションに収まる程度に小さくする必要があります

   実証可能なチャンクに分割する限り、これを行う方法について厳格な規則はありません。一般に、シナリオが 5 つまたは 6 つ以上ある場合は、同様のシナリオをグループ化することで、ストーリーを分割できる可能性があります。

ここで、あるウィザード スタイルの機能のエンド ツー エンドの受け入れテストを記述しようとしているとします (上記で検討したように)。

• ウィザード機能の使用開始時に状態がどのように異なるかによって「シナリオ」を定義するのは当然のことです (実際、これは上記のポイント 1 と 2 に適合するように思われます)。そのような独立したシナリオを作成するために、完全にシリアル化された形式で (最初から最後まで)? これにより、非常に多くのシナリオが生成されるだけでなく、それぞれが非常に多くのステップで構成されます (Dan のポイント 3 に反して)。これらのステップの多くは、シナリオが分岐する状態に到達するためだけにシナリオ間で繰り返されます。

  /li>

• 一方、ウィザード機能内の各決定分岐の開始時に、考えられる状態ごとに1 つのシナリオを定義する方が効率的です。 「イベント」は、単に機能を次のステップに進める単一のステップになります。決定分岐。しかし、これは SUT をスタックの下に移動しないので、エンドツーエンドの受け入れテストを定義するのではなく、より低い順序のものを定義することになりますか? さらに、テスト基準に従って理解することは、はるかに自然なことではありません。これは、BDD の要点全体を確実に無効にしますか?When

  このルートに進む場合、各決定ブランチを個別の機能に分割する方が正しいように思えます。そして、各ブランチのシナリオのみが 1 つの機能内で考慮されます。これは、SUT がスタックを下に移動したという私の主張を強調するだけです。

• おそらく、これらのエンド ツー エンドの受け入れテストは詳細すぎるため、ウィザード全体を (この段階では) ブラック ボックスとして扱う必要がありますか? ただし、これが顧客が何を試運転しているのかを理解するのにどのように役立つかはわかりません。特に、この機能の詳細な手順がシステム全体の受け入れ可能性の鍵となるためです。

そのような機能をシナリオに分割する最も適切な方法は何ですか?

誰かがその場でシナリオにタグを付けようとしたことがあるかどうか疑問に思っています。

ユースケースは次のとおりです。回帰テストには何百ものシナリオがあり、API がダウンしている (通常は、次回の実行時に合格することを意味します)、またはデータが変更された (つまり、スクリプトの堅牢性が不十分であり、修正する必要があるか、データを変更する必要がある)、または要件が変更された (つまり、スクリプトを変更する必要がある)。

後者の 2 つのケースでは、同じシナリオが複数回失敗するはずです。

人間の介入 (スクリプトの書き換えまたはデータの変更) が必要なものには @quarantine でタグ付けし、@regression タグを削除して、とにかく失敗することがわかっている間に何度も実行されないようにする必要があります。

私は誰もこれをしているのを見たことがありません。これは実行可能ですか？または、複雑なシェル スクリプトに頼らずに Cucumber でこれを行う唯一の方法はありますか?

私は現在、cucumber-jvm を使用して受け入れテストを推進するプロジェクトに取り組んでいます。

以前のプロジェクトでは、受け入れテストを推進するために groovy または scala で内部 DSL を作成していました。これらの DSL は非常に簡単に使用できるため、技術者でなくても少しのガイダンスでテストを作成できます。

私が見ているのは、BDD がテストに別のレイヤーの間接化とセマンティック シュガーを追加していることですが、特に非技術者が内部 DSL を使用できる場合、付加価値は見られません。

キュウリの場合、stepDefs は、特定のテストを駆動するコードをいくつかの異なるクラスに分散させているように見え、機能ファイルの外部でテスト コードを読み取り、デバッグすることを困難にします。一方、1 つのテストに関連するすべてのコードを 1 つの stepDef クラスに配置すると、stepDef の再利用が妨げられます。どちらの結果も望ましくないため、自然言語の使用にこれほど多くの価値があり、直感的ではない間接的であることに何の価値があるのでしょうか?

足りないものはありますか？ATDD と BDD の微妙な哲学的な違いのようなものですか? 前者は命令的テストを意味するのに対し、後者は宣言的テストを意味しますか? これらの美的な違いには本質的な価値がありますか?

したがって、テストを実行する実際のコードの可読性の低下を正当化する付加価値は何かという疑問が残ります。このBDDは実際に苦労する価値がありますか? 付加価値は単なる美学以上のものですか？

BDD の利点が BDD の痛みを上回る理由について、誰かが説得力のある議論を思い付くことができれば、私は感謝していますか?

複数のシナリオとシナリオごとに異なるタグを含む機能ファイルがあります。特定のタグを指定した rake コマンドを使用して Cucumber テストを実行しており、カスタム HTML レポートを作成しています。

カスタム HTML レポートは After フックで作成されます。rake コマンドで実行しているときにシナリオの数を取得する方法に関する問題に直面しています。私は

合計シナリオ数を取得しますが、これにより機能ファイルの合計シナリオ数が得られ、特定のタグでタグ付けされたシナリオ数のみを取得しようとしています。

これは StackOverflow に関する私の初めての投稿であり、問​​題全体を詳細に提供できたことを願っています。他の情報を提供する必要がある場合に備えて、お知らせください。問題の説明: あるページから別のページへのナビゲーション順序を表示する通常のブレッドクラムを使用しています。ブレッドクラムには、html 形式の id = “divbreadcrumb” があります。

例: ホームページ (Home ) から予約ページ (Bookings) に移動すると、ナビゲーションは次のようになります。

ホーム > ご予約

ブレッドクラムのテストを自動化し、ページに表示されるブレッドクラム テキストと実際のブレッドクラム テキストをチェックしたいと考えています。以下に示すコードを使用して、ATDDツール、つまりSpecflow/SpecRunおよびNunitとともにセレンWebdriverを使用して、それを達成しようとしています。

ここで、ローカルでテストを実行しようとすると正常に動作しますが、コードを TFS にチェックインしてビルドすると、IwebElement 要素からテキストが見つからないか、または返されるため、VS テスト ランナーはビルドに失敗しますString.Empty としてのテキスト。これで、同じテストをローカル マシンで実行すると、完全に正常に動作し、予想されるテスト結果と Iwebelement (ブレッドクラム) の予想値が得られます。また、上記のブレッドクラムの HTML 構造はバックエンドでレンダリングされています。これは、実行時に webdriver の pagesource プロパティを使用して HTML がレンダリングされ、例外メッセージに表示されることを確認しようとしたためです。

また、バックエンドの HTML コードは次のように表示されます。

自動化スクリプトで使用したコードを PFB して、ページのブレッドクラムからのテキストをチェックします。

私が得るエラーは

BDD プラクティスを組織に適用しようとしています。私が働いている銀行では、毎晩のバッチ ジョブが、実行中のバッチ ジョブと相互にデータをやり取りする巨大なオーケストレーション マルチシステム フローです。

テスト中、インタラクティブなオンライン テストはおそらくテスト シナリオの 40 ～ 50% にすぎず、残りはバッチ ジョブに組み込まれています。例として、テスト シナリオは次のようになります。

1. 午後 10 時現在、私の普通預金口座の残高が 100 ドルだとすると、
2. 毎晩のバッチが午後 11 時に実行される場合
3. 次に、バッチ実行が終了した後の午前 3 時に戻ってきて、$0.001 の追加の未収利息があることを確認する必要があります。
4. また、銀行の総勘定元帳には、未収利息 $0.001 のエントリが追加されているはずです。

ご覧のとおり、これは非常に非同期的なシナリオです。Cucumber を使用してトリガーする場合、午後 10 時までに 100 ドルの残高をアカウントに挿入するステップ定義をおそらく作成できますが、バッチ ジョブが午後 11 時に実行されるようにバッチをトリガーするために Cucumber を使用するのは現実的ではありません。通常、オペレータは Control-M などの独自のスケジューリング ツールを使用して実行します。そして、Cucumber を数時間待ってから、発生した利息を確認します。タイムアウトになるかどうかはわかりません。

これは 1 つのシナリオにすぎません。バッチ実行は銀行にとって非常にコストがかかるため、1 回のバッチ実行にできるだけ多くのシナリオを適用するよう常に取り組んでいます。また、定期預金期間の終了時の最終的な利息が正しいかどうかを確認するためだけに 6 か月のバッチを実行する必要があるエージング シナリオもあります (Cucumber をそれほど長く待たせて聞くことは絶対にできませんよね?)

私の質問は、BDD プラクティスがこれらのような大規模なバッチ シナリオに適用された例はありますか? これにどのようにアプローチしますか？

編集して、私が管理している分離されたテスト シナリオを実行することを目的としていない理由を説明します。

テスト レベルの 1 つで個別のシナリオを実行し (私の銀行ではシステム テストと呼んでいます)、BDD は実際にそのコンテキストで機能します。しかし最終的には、エンド ツー エンド環境全体 (通常は SIT) を持つテスト レベルに到達する必要があります。この環境では、複数のテスト シナリオを並行して実行することが条件であり、いずれのシナリオも環境を完全に制御することはできません。プロジェクトの範囲によっては、この環境で最大 200 個のアプリケーションを実行できます。そのため、インターネット バンキングなどの顧客チャネルではトランザクション シナリオが実行され、コア バンキング システムでは金利計算や自動送金などのシナリオが実行されます。総勘定元帳システムが環境内のすべてのアカウントを統合してバランスをとる会計シナリオもあります。

私がやろうとしているのは、BDD フレームワークを活用してテストの実行を自動化し、結果をキャプチャして、環境内のすべてを手動で追跡する必要がないようにする方法を見つけることです。

WebApi と IdentityServer の受け入れテストを作成したいと考えていました。できるだけ単純にするために、ここからサンプル プロジェクト全体をコピーしましたが、別のプロジェクトを追加しました。これにより、基本的にコンソール クライアントと同じですが、受け入れテストが行​​われます。

私が今得た唯一のシナリオはこれです：

「ok」ではなく「unauthorized」というステータス コードが常に表示されるようになりました。コンソール クライアントを介して 2 つのサーバーを呼び出すと、期待どおりに動作します。とてもイライラします。

更新 「サービスを呼び出すとき」の手順を次の行に置き換えて、単純さを高めました。

問題は同じです: HttpRequestException がスローされます (401 無許可)。