タグ付けされた質問 「bdd」

最近、Literate Programmingについて少し読んで、考えさせられました...よく書かれたテスト、特にBDDスタイルの仕様は、散文よりもコードが何をするかを説明するのにより良い仕事をすることができ、大きな利点があります自身の精度を検証します。 テストするコードとインラインで記述されたテストを見たことはありません。これは、言語が同じソースファイルに記述されたときにアプリケーションとテストコードを簡単に分離する傾向がないため（そして誰も簡単にしなかったため）、または人々がテストコードをアプリケーションコードから分離するより原則的な理由があるからですか？

91 testing  unit-testing  bdd  literate-programming 

この質問の簡単な紹介。私は現在TDDと最近BDDを1年以上使用しています。私は、モックなどの手法を使用して、テストをより効率的に記述します。最近、私は自分のために小さなお金管理プログラムを書くための個人的なプロジェクトを始めました。レガシーコードがなかったため、TDDから始めるのに最適なプロジェクトでした。残念ながら、TDDの喜びはあまり経験しませんでした。それは私の楽しみを台無しにし、プロジェクトをあきらめました。 なにが問題だったの？さて、TDDのようなアプローチを使用して、テスト/要件がプログラムの設計を進化させました。問題は、テストの作成/リファクタリングに関して、開発時間の半分以上がかかっていたことです。したがって、リファクタリングして多くのテストに書き込む必要があるため、最終的にはこれ以上機能を実装したくありませんでした。 職場では、レガシーコードがたくさんあります。ここでは、統合テストと受け入れテストを増やし、単体テストを減らしていきます。ほとんどのバグは受け入れテストと統合テストによって検出されるため、これは悪いアプローチではないようです。 私の考えは、最終的には単体テストよりも多くの統合テストと受け入れテストを書くことができるということでした。バグを検出するために言ったように、単体テストは統合/受け入れテストよりも優れていません。単体テストも設計に適しています。私はそれらの多くを書いていたので、私のクラスは常にテストしやすいように設計されています。さらに、テスト/要件が設計をガイドできるようにするアプローチは、ほとんどの場合、より良い設計につながります。単体テストの最後の利点は、高速であることです。ユニットテストとほぼ同じ速度で実行できることを知るために、十分な統合テストを作成しました。 ウェブを調べた後、私の考えによく似たアイデアがあちこちであることがわかりました。この考えをどう思いますか？ 編集 質問には、デザインは良かったが、次の要件のために大規模なリファクタリングが必要な例の1つに答えました。 最初は、特定のコマンドを実行するためのいくつかの要件がありました。拡張可能なコマンドパーサーを作成しました。これは、ある種のコマンドプロンプトからコマンドを解析し、モデル上で正しいものを呼び出しました。結果は、ビューモデルクラスで表されました。 ここには何も問題はありませんでした。すべてのクラスは互いに独立しており、新しいコマンドを簡単に追加し、新しいデータを表示できました。 次の要件は、すべてのコマンドに独自のビュー表現（コマンドの結果の何らかのプレビュー）が必要であることです。新しい要件に対してより良い設計を実現するために、プログラムを再設計しました。 これは、すべてのコマンドに独自のビューモデルがあり、したがって独自のプレビューがあるためです。 問題は、コマンドパーサーがコマンドのトークンベースの解析を使用するように変更され、コマンドを実行する機能が削除されたことです。すべてのコマンドには独自のビューモデルがあり、データビューモデルは、表示する必要があるデータを知っている現在のコマンドビューモデルのみを知っています。 この時点で私が知りたかったのは、新しいデザインが既存の要件を満たさなかった場合のみです。受け入れテストを変更する必要はありませんでした。ほぼすべての単体テストをリファクタリングまたは削除する必要がありましたが、これは膨大な作業の山でした。 ここで見せたかったのは、開発中によく発生する一般的な状況です。古いデザインでも新しいデザインでも問題はありませんでした。要件に応じて自然に変更されただけでした。私がどう理解したか、これはTDDの利点の1つであり、デザインが進化します。 結論 すべての答えと議論をありがとう。この議論の要約として、次のプロジェクトでテストするアプローチを考えました。 まず、いつものように何かを実装する前に、すべてのテストを作成します。 要件については、最初にプログラム全体をテストする受け入れテストをいくつか作成します。次に、要件を実装する必要があるコンポーネントの統合テストをいくつか作成します。この要件を実装するために別のコンポーネントと密接に連携するコンポーネントがある場合、両方のコンポーネントが一緒にテストされる統合テストも作成します。最後になりましたが、アルゴリズムまたは他のクラスを高い順列（シリアライザーなど）で記述する必要がある場合は、この特定のクラスの単体テストを記述します。他のすべてのクラスはテストされませんが、単体テストが行​​われます。 バグについては、プロセスを簡素化できます。通常、バグは1つまたは2つのコンポーネントによって引き起こされます。この場合、バグをテストするコンポーネントの統合テストを1つ作成します。アルゴリズムに関連する場合は、ユニットテストのみを記述します。バグが発生したコンポーネントを簡単に検出できない場合、受け入れテストを作成してバグを特定します。これは例外です。

62 testing  unit-testing  tdd  bdd  integration-tests 

BDDとTDDの関係は何ですか？ 私が理解したことから、BDDはTDDよりも2つの主要なものを追加します。テストの命名（保証/すべき）と受け入れテストです。BDDによる開発中にTDDに従う必要がありますか？「はい」の場合、TDDユニットテストの名前は同じシュア/スタイルで指定する必要がありますか

30 tdd  bdd 

重いjquery / backbonejs Webアプリケーションで100％のコードカバレッジを期待することは可能ですか？javascript / jqueryで実際のコードカバレッジが92％から95％前後で推移する場合、100％のカバレッジが満たされないためにスプリントに失敗するのは妥当ですか？

28 code-quality  tdd  bdd 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私はこれがあるとは思いません起動するには、繰り返しの他の質問にユニットテスト。私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、ユニットテスト（JUnitなど）、BDD（JBehave、Fitness）、UI（Selenium、Watir）を区別する必要はないと思います。同意しない答えを書いてください:)） 以下は私が特定したリストです。拡張または改善に役立つ答えを探しています： 時間/コストの節約：自動化されたテストの作成は、テストケースの作成よりも時間がかかる場合があります。ただし、テストが複数回実行されることを考慮すると、自動テストを実行するためのわずかな作業（コスト/時間）が数桁少なくなります。自動テストの実行が安価であることは、時間の経過に伴うシステムの変更を促進します。 ドキュメンテーション：システムがどのように機能するかを知るためのより正確な方法は、テストよりもありません。他のドキュメントは、通常、作成された時点では古くなっていますが、テスト（少なくとも合格したもの）により、実際の動作が明らかになります。これは、エンドユーザーおよびAPIドキュメントの両方に当てはまります。 コード品質：テスト作成により、次のことが強制されます。 テストはクライアントであるため、クライアントを考慮する コードをテスト可能にすることは、多くの場合、他の大規模システムを必要としないコードを作成する方法を見つけ出すことを意味します。

25 unit-testing  selenium  tdd  bdd 

象徴的な「Given-When-Then」シナリオ構文を使用した動作駆動型開発は、ソフトウェア機能評価の境界オブジェクトとして使用できる可能性があるため、最近非常に誇張されています。 Gherkin、またはどちらの機能定義スクリプトでも、ビジネスで読み取り可能な DSLであり、すでにそのような価値を提供していることは間違いありません。 ただし、プログラマではない人が書き込み可能であることに同意しません（Martin Fowlerも同様です）。 プログラマ以外の人が作成し、開発者がインスツルメントしたシナリオのアカウントを持っている人はいますか？ 書き込み可能性の欠如についてコンセンサスがある場合、シナリオを開始してそれらをインストルメント化する代わりに、実際のテストからビジネスで読み取り可能なシナリオを生成するツールに問題がありますか？ 更新：「シナリオジェネレータ」ツールに関しては、もちろんビジネス言語を魔法のように推測することはありません;）しかし、現在、正規表現マッチャーを使用して（抽象化次元で）トップダウンアプローチでテストを作成するように、ボトムアップアプローチでシナリオを作成する文字列ビルダー。 「アイデアのみを提供する」例： Given I am on page ${test.currentPage.name} And I click on element ${test.currentAction.element} …

24 documentation  bdd  documentation-generation  business-rules 

そのため、テストの価値を本当に理解していない人から何度も聞いています。物事を始めるために、私はアジャイルとテストのフォロワーです... 私は最近、製品の書き換えでTDDを実行することについて議論しました。現在のチームはどのレベルでも単体テストを練習しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがないでしょうコードをきれいにするために）。 現在、私はこの製品の書き換えについて完全に責任を負っており、TDDのように試してみると、単にメンテナンスが悪夢になり、チームがメンテナンスすることが不可能になると言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。ビジネスドライブが変化すると（当然、改善を意味します）、テストは時代遅れになります。将来のプロジェクトはそれらを維持せず、彼らが修正するなどの負担になるでしょう。 現在、テスト経験のないチームのTDDは良く聞こえないことは理解できますが、この場合の私の主張は、周囲に練習を教えることができるということですが、さらに、TDDがより良い結果をもたらすことを知っていますソフトウェア。TDDを使用してソフトウェアを作成し、メンテナンスチームに引き渡す際にすべてのテストを破棄する場合でも、TDDを最初から使用しないよりも確実に良い方法でしょうか。 TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うことについて言及したので、私は撃downされました。「インターフェイス」と奇妙な外観のDIコンストラクターの考えは、それらを怖がらせます... 通常、TDDを販売しようとするという非常に短い会話や、人々への私のアプローチについて、誰か助けてください。会社/チームにひざまずく前に、私は通常非常に短い議論の窓を持っています。

24 testing  agile  tdd  bdd 

BDD（Behaviour Driven Development）について読んだすべてのWebサイトで、要件を定義することがいかに明白で簡単かを示す非常にシンプルで素晴らしい例が見つかります。しかし、このプロセスを（電卓の例ではなく）大きな製品に実装しようとすると、物事がかなり複雑で読みにくくなる（または得られる）ことがわかりました。特に後でリクエストを変更することは、このための統合テストを修正するための多くの作業を意味します。 だから、BDDは本当に価値があるのだろうか？他の手法では解決できない問題を解決できますか？

22 development-process  scalability  bdd  integration-tests 

ユニット/機能テストなしの大規模なエンタープライズレベルのアプリケーションがあるとします。非常に厳しい締め切りのために、開発中にテスト駆動型の開発プロセスはありませんでした（わからない場合、締め切りを約束するべきではありませんが、何が行われたかはわかりません！） すべての期限が過ぎ、物事が落ち着いたので、誰もが生産的なTDD / BDDベースのチームに私たちを変えることに同意しました。 問題は、すでにあるコードについてです：（1）すべてが完全に正常に動作していても、ほとんどの開発を停止し、最初から可能なテストケース全体を書き始めることはまだ大丈夫ですか？ ？または、（2）何か悪いことが起こるのを待ってから、修正中に新しい単体テストを作成するか、（3）以前のコードを忘れて、新しいコードのみの単体テストを作成し、次の主要なリファクタリングにすべてを延期する方がよいでしょう。 このようないくつかの良い関連記事があります。私たちには非常に限られた時間しかなく、他の多くのプロジェクト/作品が私たちを待っているので、これに投資する価値があるかどうかはまだわかりません。 注：この質問は、開発チームの完全に厄介な状況を説明/想像しています。これは私や同僚のことではありません。それは単なる想像上の状況です。これは絶対に起こらないか、開発マネージャーがそのような混乱に責任があると思うかもしれません！しかし、とにかく、行われたことが行われます。可能であれば、これは絶対に起こらないと思われるからといって、投票しないでください。

17 unit-testing  testing  tdd  bdd  acceptance-testing 

私はBDDを理解しようとしています。いくつかの記事を読みましたが、理解したように、BDDはTDDの「次のステップ」です。私は両方とも非常に似ていると思うので、この記事で読むことができるように、TDDからの改良としてBDDが生まれたと言います。素晴らしい、私はアイデアが本当に好きです。 考えられない実用的なポイントが1つあります。BAがシステムが持つすべての予想される動作を書き込む.featureファイルがあります。BAとして、彼はシステムがどのように構築されているのかわからないので、次のように書きます。 +シナリオ1：アカウントにクレジットがあります+ アカウントにクレジットがあることを考えると そして、カードは有効です そして、ディスペンサーには現金が含まれています 顧客が現金を要求するとき 次に、口座から引き落とされていることを確認し、現金が支払われていることを確認します そして、カードが返されることを確認してください わかりました、これは素晴らしいことですが、システムの多くの部分が連携してそれを実現します（Account obj、Dispenser obj、Customer objなどを考えてください）。私にはこれは統合テストのように見えます。 ユニットテストが欲しいです。ディスペンサーにお金があるかどうかを確認するコードをテストするにはどうすればよいですか？または、現金が分配されますか？または、必要なときに口座から引き落とされますか？ ユニットテストと「BA Created」テストを混在させるにはどうすればよいですか？

17 unit-testing  bdd 

TDDには、アレンジアサート（AAA）構文があります。 [Test] public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned() { //Arrange ShopStock shopStock = new ShopStock(); Item blackSweater = new Item("ID: 25"); shopStock.AddStock(blackSweater); int expectedResult = 2; Item blackSweaterToReturn = new Item("ID: 25"); //Act shopStock.ReturnItemForRefund(blackSweaterToReturn); int actualResult = shopStock.GetStock("ID: 25"); //Assert Assert.AreEqual(expectedResult, actualResult); } BDDの記述テストでは、同様の構造を使用しますが、Given When Then（GWT）構文を使用します。 [Given(@"a customer previously bought a black sweater …

13 c#  unit-testing  tdd  bdd 

自動受け入れテストでユーザーストーリーを100％網羅したBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何ですか？ 開発者が受け入れテストを製品所有者と一緒に書くことを想像していると思いますが、それが馬鹿げた仮定のように思えたら教えてください。

13 testing  team  qa  bdd  acceptance-testing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 3年前に閉店しました。 私はこれが多少主観的であることを理解していますが、どちらかの良いケースを見つけることができません： 「何かをする必要がある」 「何かする」 推奨スタイルの支持者は、それがあなたが達成しようとしていることを実際に質問することを強制するが、批判者はそれを単に冗長であると感じていると述べている。 これについてコンセンサスがありますか、それとも純粋にスタイルの問題ですか？

12 testing  bdd 

Q：要件データベースで少なくとも15年間のレガシーソフトウェア要件を維持しながら、大企業をCucumberに移行する最良の方法は何ですか？ 現在検討中： 1）すべてを移行する マイナス面：無制限の時間/予算がない、生き残るために前進しなければならない、すべてを止めることはできず、レガシー要件とレガシーテストスイートの100％をGCする。 2）ボーイスカウトルール あなたがそれを見つけたよりもすべてを残します。要件に触れたり変更したりする場合は、キュウリ機能を作成/更新します。欠点：2つのシステムの記録（Cucumber、legacy req。DB）があります。おそらく、与えられたアプリケーションの隅に非常に長い間触れられないことを永遠に想定しています。 3）ボーイスカウトルールプラス ＃2と同じですが、単一の保留シナリオを使用してCucumberに移行しないネット要件を機能に追加し、レガシー要件をコピーして説明セクションに貼り付けます。このようにして、Cucumberがどの程度「カバー」されているかに関するメトリックを（保留中のシナリオを介して）取得します。また、古い要件システムを維持する必要性に乗ります。それがCucumber内の巨大な混乱であるかもしれないので、これ以外の欠点を見つけることはできません。 4）ここにアイデアを挿入します。 バックグラウンド： Cucumberに移行するプロジェクトには自動化されたテストスイートがあり、一部のプロジェクトでは手動テストのみが使用されています。それらはすべて、レガシー要件データベースで要件を維持します。要件は法律/規制と金融商品の複雑なロジック（リスク、価格設定、構造など）が混在しているため、これを行う必要があります。 これは非常に大きな会社であるため、ソリューションをさらに複雑にしていることに留意してください。 「新しい」要件のためにCucumberを使用するプロジェクトが既にいくつかあります。それで、私たちはこの技術を試してみましたが、これは私たちにとってこれまでのところうまくいきました。Webプロジェクトと純粋なデータプロジェクトが混在しています。 ありがとう 編集：質問に回答するには...従来の要件管理DBは、要件をテストに関連付けません。「テスト可能」ではありません。現在、要件をテストに接続することは、各プロジェクトの最後に、要件をテストケース管理システムにリンクする、困難でエラーが発生しやすい手動プロセスによって行われます。キュウリは私たちにとって明らかに優れたソリューションです。それについての質問はありません。問題は、法的な理由や他の理由で失われることのない、膨大な量の重要な要件を抱える大規模な組織をどのように動かすかです。

11 bdd  cucumber 

私は、行動駆動開発方法論（別名BDD）の声明的な支持者です。私は数年前からBDDを適用してきましたが、DotNetアプリケーションを開発する際の選択のフレームワークとしてStoryQを採用しました。私は長年ユニットテストを行っており、以前はテストファーストのアプローチに移行していましたが、BDDフレームワークを使用することでより多くの価値が得られることがわかりました。コード内の英語をクリアします。テストはテストを途中で終了することなく複数のアサーションを実行できるため、デバッグすることなく、どの特定のアサーションが合格/失敗するか一目で確認できます。 これは本当に私にとって氷山の一角でした。テストコードと実装コードの両方をより的を絞った方法でデバッグできることにも気づきました。その結果、生産性が大幅に向上し、ビルドログに出力されるために問題が統合ビルドに至るまでに発生した場合、障害が発生した場所を簡単に判断できます。さらに、StoryQ apiには、習得が容易で、非常に多くの方法で適用できる美しい流な構文があり、使用するために外部の依存関係を必要としません。 したがって、これらすべての利点があれば、チームの他のメンバーにこのコンセプトを簡単に導入できると思います。残念ながら、他のチームメンバーはStoryQを見てそれを適切に評価することを嫌がり（BDDを適用するというアイデアを楽しまないでください）、お互いの説得力のあるテストフレームワークから多くのStoryQ要素を削除しようと互いに確信していますただし、元々StoryQの使用をサポートしており、削除したいコードがテストシステムの他の部分に影響を与えることはありませんでした。そうすると、特定の作業環境でテストファーストで作業するより良い方法であり、より大きな結果につながるだけであると実際の経験から確信しているので、全体的にワークロードが大幅に増加し、実際に穀物に反することになります私のソフトウェアの品質の改善 veは、BDDを使用して最初にテストに固執する方が簡単だと感じました。さらに明確にするために、私たちが行った単体テストの大部分は非常に脆弱で維持が難しい傾向があります。テスト駆動型プロセスに固執することを嫌がって開発者が古い習慣に戻り、プロジェクトの最後にすべてのテストを行います（同じ人がアジャイルだと主張しています！）。 したがって、質問は次のようになります。 このチームがStoryQを使用すること、少なくともBDD方法論を採用することの方が良いと主張するために、どのような議論を使用できますか？ BDDを標準的な選択方法として採用するという私の主張を裏付けるために使用できる事例証拠を教えてください。 チームがBDDを採用することを奨励したいという私の希望が間違っている可能性があることを示唆する反論はありますか？はい、議論が健全なものであれば、間違っていることが証明されてうれしいです。 注：テスト全体を書き直すことを推奨するのではなく、将来のすべてのテスト作業のために、できればお客様と交わる方法で異なる方法で作業を開始することを推奨します。 また、BDDの詳細については、次のリンクが役立ちます。 http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/Introduction 詳細に興味がある人のために、私たちは4人の小さなチームで約5つの大きなプロジェクトに取り組んでいます。BDDの「パイロットトライアル」は、最初は約2か月間、その後約4か月間実行されました。チームは、私がこの方法で作業を続ける必要があることを受け入れ、独自のトライアルを行うことになりました。トライアルが終了してから約2年間BDDを行っていますが、他の人は問題をうまく解決することができました。この問題について「対立」を強要するのではなく、私はチームを優しく説得して、集団の背後から抜け出し、少し時間をとる方法を探しています。

11 productivity  agile  unit-testing  bdd