問題タブ [atdd]

私は週末に取り組む型を与えられました。それを始める前に、私は本当にいくつかの考えを集めたかった. 私は解決策を探しているのではなく、最良のアプローチ/プラクティスに関するいくつかのアイデアです。

私が行った会話から、BDD --> ATDD (ガーキンのシナリオに関連) --> TDD アプローチを使用する必要があるように思われます。私はただ最善のアプローチを模索しているだけです。

私の現在の考えは、

1) specflow プロジェクトを作成し、ユーザー ストーリーをガーキンに抽出します。

2) GWT 構文を使用してガーキン (シナリオ) で関連する受け入れテストを作成し、[バインディング] クラスで私の ATTD スタイル テストを生成します (「生成」を右クリックします)。

3) gherkin ATDD テストに合格します。

私が抱えている難問は、ガーキン ファイル内の ATTD テストに直接リンクしているテストでは、低レベルの十分なテストが得られないということです。

それで、私は何をしますか？高レベルの ATDD テストを作成し、合格する前に、より深く掘り下げて純粋な TDD テストを作成し、低レベルのオブジェクトを設計しますか?

ええ、私は完全に BDD 方式 (純粋なスタイル) で作業する方法をまだ考えていないので、どのように掘り下げるか疑問に思いました。段階的に作業を進めて 1 つのテストを完了して合格する必要があることを感謝しますが、高レベルの ATDD テストから始めてさらに深くする必要があると感じているため、低レベルのコードが機能するまで高レベルのテストは機能しませんが、従う必要があります。 TDD その低レベルのコードをテストする必要があるため、1 つの単体テストをパスしてからリファクタリングするという原則を既に破っています.....

実際にやらずにこれにアプローチする「方法」を誰かが教えてくれることを願っています。しかし、ここに私に提供された問題があります...（テスターがこれを見た場合、ここで質問したことで失敗する可能性がありますが、仕事を得るよりも学ぶことがより重要です）。はい、私は怒っていることを知っています:-)

また、純粋な TDD テスト用に別のプロジェクトを作成する必要があるかどうかも知りたいです。最適なプロジェクト構造は? 1 つの specflow プロジェクトと .test プロジェクト、クラス ライブラリ、およびランタイム用のコンソール アプリを考えています。

PSこれを手伝ってくれる人は誰でも、私から彼らに恩恵を受けています。抱擁または慈善寄付。または、ここの+1だけがあなたが本当に欲しいものだと思います:-/

最初はグー、じゃんけん

ゲームを知りませんか？http://en.wikipedia.org/wiki/Rock-paper-scissors

私は縮小版を探しています (最小限の実行可能な製品を考えてください)。データベースなし (つまり、保存されたセッション)、単純なインターフェース - 2 時間または 3 時間分の作業 (トップ) は完全に合理的です。私は本格的なものを探しているのではなく、よく作られた小さなものだけを探しています. これが .NET ではなく Java であり、よりバックエンド指向である場合は、コンソール アプリで間に合わせます。C# で単体テストと適切に分解されたコードを探しています。私が探しているのは、たまたま C# ASP.Net MVC を使用しているコーダーです。

受け入れテスト駆動開発 (ATDD) に関する質問があります。私のアプリケーションは、Web サイト、モバイル、デスクトップなどの複数のクライアントを持つ可能性のある REST サービスとして開発されています。ATDD の概念では、すべての機能をエンド ツー エンドのテストから開始する必要があります。私のサービスには、同じユースケースを提供する複数のクライアント アプリケーション (エンド) がある可能性があるため、受け入れテストを作成するときにどのアプローチを使用する必要がありますか? 受け入れテストは、REST サービスまたはクライアント アプリへの直接要求を入力として受け取る必要がありますか? または両方？受け入れテストが REST 要求から開始する場合、クライアント部分を省略していることは理解していますが、これはまったく問題ありません。これらがクライアントから開始する場合、すべてのクライアントに対して基本的に同じ機能テストを繰り返します。これらの境界の中間にとどまるアプローチを見つける必要があります。

フォーム フィールドでオプションを選択しようとする Behat 機能ファイルを実行しています。

ここで、「Lisa Hayes」はフォーム名「settings_custom[カウンセラー][]」の値の 1 つです。要素の詳細は次のとおりです。

コマンド ラインで機能ファイルを実行するとエラーが発生する

ID|名前|ラベル|値「settings_custom[カウンセラー][]」のフォーム フィールドが見つかりません。

デフォルトのドライバーは selenium2 です (バックグラウンドで実行されている selenium-server-standalone-2.32.0.jar サーバーがあり、ブラウザーは firefox です)。

これは、デフォルトのドライバーを Selenium (Web ドライバー) から goutte (ヘッドレス) に変更すると完全に機能することに注意してください。

このフォーラムを検索しようとしましたが、Google で詳細を検索しましたが、役立つ情報は見つかりませんでした。

さらに情報が必要な場合はお知らせください。ありがとう！

何らかの理由で、私のコードは 1 つのフォーマッターを使用している場合にのみ実行されます。

別のものを追加すると：

IndexOutOfBoundsException が発生します。

別のものを追加すると：

今度は別の IndexOutOfBoundsException が発生します = -1:

何が起こっているのかを理解するのを手伝ってくれる人はいますか!!!!?

バージョン:

オンライン フォーラムや投稿からわかることによると、BDD/ATDD の主な焦点の 1 つは、議論と、顧客、開発者、テスター、およびその他の関係者がシステムが何をする必要があるかを理解することに関与していることを確認することです。

質問 1: BDD/ATDD ストーリーは、Volere テンプレートを使用してキャプチャされたものなど、従来の要件仕様の必要性を置き換えるものですか?

従来の要件仕様は開発者とテスト担当者にとって重要なインプットの 1 つであるため、従来の要件仕様は包括的である傾向があります。

質問 2:システムを完全にテストできるように、BDD/ATDD ストーリーも十分に包括的である必要がありますか?

私は、gerrit を使用してユーザー ストーリーをキャプチャし、コラボレーションするプロセスを継承しています。

このプロセスは、ストーリーをキャプチャする非常に初期の段階で使用され、ホワイトボード アプローチと比較すると、非常に時間がかかります。

このプロセスは、コラボレーションや対面での議論が好まれるように見えるユーザー ストーリーの精神に反しているように感じます。

また、gerrit ツールは、より技術的なユーザーを対象としています。ストーリーの編集には git の知識が必要であり、ストーリーの作成を技術チームに押し付けているようです。

質問: gerrit を使用してストーリーを効果的にキャプチャし、コラボレーションすることは可能ですか? もしそうなら、どうすればこれを行うことができますか？

オンライン資料 ( FowlerやGerardなど) を読むと、Specification By Example の記事は機能の完全な仕様ではないように思われます。

質問 1 : SBE から始める人は、システムのすべての機能を説明するという点で、ストーリーがどの程度包括的である必要があるかをどのように判断しますか? つまり、十分にキャプチャしたので、いつストーリーを書くのをやめることができますか?

質問 2 : テスト チームが製品ドキュメントに照らして製品を検証する組織で、ストアが完全な仕様でない場合、「その他の」製品ドキュメントには SBE でカバーされていないすべてのケースを含める必要があると考えるのは正しいですか?

私は、製品の動作を定義するために SBE 仕様が作成されている、かなり大規模な既存のコード ベースに取り組んでいます。

現在、約 450 のシナリオがあり、この数はコード ベースに新しい機能が追加されるたびに増加しています。

従来の 1 行の要件ステートメントと比較して、SBE 仕様の冗長な性質のために、システムの機能を高レベルで理解することは困難です。例として、ストーリーには現在合計 46,830 語があります。

もう 1 つの問題は、ストーリーの共同作業にgerrit コード レビューツールを使用していることです。これにより、チーム間のコミュニケーションが正式化されています。

質問 1 : SBE は完全で包括的な回帰テスト スイート (例) である必要がありますか? それとも、各スプリントで必要な主要な機能のみに集中する必要がありますか?

質問 2 :こちらの回答で述べたように、大規模なプロジェクトのストーリーを管理するために課題トラッカーなどのツールが必要ですか?

既存のシステムに継承した多くの BDD ストーリー/シナリオ (450 以上以上) があります: 詳細. ストーリーは、ファイル システム フォルダーを使用して編成されます。

非常に多くのストーリーがあるため、ストーリーのテキスト ファイルを読んで機能を理解しようとすることは、何千行ものソース コードを読んでシステムの技術アーキテクチャを理解しようとするようなものです。

コマンドを使用してストーリーを要約しようとしましunixたが、それでもストーリーをナビゲートするのに役立ちません。たとえば、次のコマンドは、物語が複数行にまたがる場合でも、物語のファイル名と物語を出力します。

次のような出力が生成されます。

この質問はこの質問に似ていますが、いくつかの重要な違いがあります。

• この質問の焦点は、ストーリーを要約してナビゲートすることであり、きれいに印刷することではありません.
• 高レベルから詳細までズームインおよびズームアウトする必要性。
• ナビゲーションは、ビジネスだけでなく、ストーリーを理解する必要がある人によって行われます。