問題タブ [bdd]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
548 参照

ruby-on-rails - 特にRailsアプリケーション向けのTDD/BDD

アプリケーションの開発に TDD/BDD メソッドを使用する場合、どの程度の粒度を取得する必要がありますか? 特にRailsアプリケーションに関して。

すべての単一フィールドを個別にテストしてから、合格する移行を修正しますか? それでは、すべてのフィールドに独自の移行がありますか? フィールドが彼らのものであることを確認するために、実際に何をテストしますか?

私は本当に、どこから始めて、どのくらい細かく取得するかについて頭を悩ませようとしています. 私はすべての小さなことをテストする方法がわからないので、始めてフリーズします。

私が見た例のほとんどは、検証を例として使用しています。その前にもっと多くのコードが書かれていることは知っていますが、「名フィールドが必要」などの最も基本的なことをテストする方法がわかりません。

どんな助けでも大歓迎です。

ありがとう!

0 投票する
2 に答える
236 参照

.net - 複数の継承された動作を可能にするBDDスタイルのフレームワークはありますか?

システムテストの多くはBDDスタイルで記述されており、重複を最小限に抑えるために継承された動作を適切に利用しています。たとえば、これは購入テストの基本的な階層である可能性があります。

この場合、BehavesLikeSuccessfulPurchaseアカウントステートメントにデビットエントリが必要であるなどの一般的な動作をBehavesLikePurchaseWithValidCreditCard定義し、クラスは有効なクレジットカードを使用して任意のタイプの製品を購入するためのテストワークフローを定義するため、テストは具体的な製品インスタンスを提供するだけの小さな派生クラスです。 、例えば

ただし、具体的な製品タイプによっては、追加のチェックも必要です。たとえば、ビデオが正常に購入されるたびに、ユーザーのビデオライブラリに追加されていることを確認します。理想的には、これは別のクラスによって定義され、架空の構文を使用して混合される可能性があります。

ただし、もちろんC#は多重継承やミックスインをサポートしていないため、追加の動作に呼び出しを転送するボイラープレートメソッドを大量に作成することになります。この動作は、動作が変わるたびに変更する必要があります。

私たちが本当に必要としているのは、観察すべき追加の動作のタイプを提供するだけで、テストからの複数の動作をサポートする独自のメカニズムを備えたフレームワークです。私はxUnitと仕様の例を見てきましたが、そのトリックを実行できるいくつかの拡張機能を考え出すことは可能であるように見えますが、すでに存在するものはありますか?

0 投票する
1 に答える
255 参照

model-view-controller - BDD Top-Down Approach

I'm new in BDD world and I've been in some difficult trying to get the best from top-down approach, strongly recommended by many people. Considering this what would you recommend as a good start point to specify controller's behaviors? I mean, what need to be tested in a CRUD controller scenario for example?

Regards,

Alex

0 投票する
6 に答える
3279 参照

ruby-on-rails - TDD / BDD Rails Cucumber/RSpecの複製

誰かがSIMPLEユーザーストーリーを使用して、Cucumberが何に使用され、RSpecが何に使用されるかについての完全なスライスを明確にできますか?先日、RSpecの本を購入して、それを読んでいます。作者は時々かなり漠然としているようです。

ユーザーストーリーが次のようなものである場合に私が考えていること(構文の誤りを許してください、これはあなたが要点を理解するためです):

ユーザーが無効な電話番号を入力すると、「無効な電話番号」というメッセージが表示されます

これをチェックするためにCucumberのすべてのコードを書き、次にrspecのものを書く場合、基本的にテストを複製しています。キュウリのテストがrspecのテストとどのように異なるべきかを説明するシナリオはありますか?

いつも両方のレベルでテストを複製しているような気がします。

これについて決定的な答えがない場合、私はキュウリの人々がRSpecの人々のつま先を踏みたくなかったと思い始めます。

助けてください。頭が爆発しそうな気がします。

ありがとう!

0 投票する
1 に答える
138 参照

php - シナリオ/ストーリーは BDD/TDD の新しいインターフェイスですか?

PHP には (まだ) 戻り値の型がないため、多少機能が低下しています。X が既に存在する場合に例外をスローするには、コードが必要です。これをシナリオに書くことはできますが、シナリオから自分のクラスが実装するインターフェイスに進むことができません。

実際、この問題はTDDでも同じだと思います。インターフェースよりも、「テスト」を通じてわかることの方が多いようです。それでも私のインターフェイスは、どのコンポーネントが相互作用できるか、どのような責任を負うべきかを定義します。

PHP には戻り値の型がないため、問題はより大きくなりますが、x の場合に例外をスローする必要があるという契約がないため、他の言語にも存在します。

どうすればこれに対処できますか?

0 投票する
2 に答える
323 参照

bdd - BDDと「いつ」の場所

私は、BDD への 2 つのアプローチのように思われることを見てきました。違いは、「いつ」の場所にかかっています。

アプローチ 1 では、when は仕様の一部です。

純粋な「その時与えられた」用語では、これは次のとおりです。

「空のスタックが与えられた場合、それがプッシュされると、空ではなくなります。」

したがって、「いつ」は指定方法の一部です。

アプローチ 2 では、when はクラス レベルで定義されます。つまり、 when は通常、セットアップで呼び出されます。

好ましい方法はありますか?動作の純粋なテストに関しては、テスト フィクスチャの焦点が動作にあるため、2 番目のオプションが望ましいと思われます。

ただし、テストを簡単にするために、最初の方法に傾いています。私がテストで見つけた苦労のほとんどはセットアップです。つまり、特定の状態で SUT を取得する必要があります。その状態になると、通常、実際に何らかの動作を呼び出すコードは 1 行だけです。そのため、クラスごと (つまり、セットアップ コンテキストごと) に複数の動作を設定すると、クラスの 1 回限りのセットアップが活用されます。

だから、私は考えを探しています。1 つのアプローチが他のアプローチよりも優先されますか?

0 投票する
3 に答える
699 参照

javascript - JavaScript用のどのBDDフレームワークを使用していますか?

ExtJSフレームワークを使用して大規模なアプリケーションを開発しています。成長が速すぎるので、今がテストを始める時期かもしれないことに気づきました。

BDDテクニックを使いたいのですが、JavaScript用のBDDフレームワーク(Screw.Unit、JSpec、JSSpec)がいくつか見つかりましたが、どれを選択すればよいかわかりません。このトピックに関するいくつかの記事がありますが、私はあなた自身の経験/提案にもっと興味があります。

だから私の質問は:

  • どちらを使用しますか、またその理由は何ですか?
  • その他のヒント/ヒントは大歓迎です。
  • BDDテストと一緒にSeleniumを使用していますか?
  • 他のテクニックを使っていますか?
0 投票する
2 に答える
1112 参照

resharper - MSpec BDD フレームワークをインストールするには?

R# や TestDriven.NET をサポートする MSpec インストーラーがあるかどうか知っている人はいますか?

0 投票する
3 に答える
1311 参照

ruby-on-rails - Railsコントローラーのテストでモデルをモックする必要がありますか?

コントローラーの例でモデルをモックアップしているため、カバレッジに穴が開いています。コントローラが依存しているモデルのメソッドを削除しても、失敗は発生しません。

静的に型付けされた言語のTDDから来て、私は常に、速度を上げるためにデータベースにヒットするテスト対象のオブジェクトへの依存関係を模倣していました。上記の例では、モックが元のオブジェクトをサブクラス化したため、引き続き失敗します。動的言語でのベストプラクティスを探しています。

ありがとう。

アップデート:

これについて多くの相反する意見を得た後、それはあなたがどの哲学に賛成するかに要約されるようです。

Rspecコミュニティは、テスト対象のオブジェクトの分離を実現するために、依存関係を大幅にスタブ化するように見えます。受け入れテスト(従来は統合テストと呼ばれていました;)は、オブジェクトが実行時の依存関係で機能することを確認するために使用されます。

shoulda / Test :: Unitコミュニティは、可能な限りスタブを避けているようです。これにより、テスト対象のオブジェクトが実際にその依存関係で機能することをテストで確認できます。

このビデオはこれをうまく要約しています:http://vimeo.com/3296561

0 投票する
3 に答える
376 参照

c# - TD.NETを使用したNBehaveプレーンテキストシナリオの実行

これは可能ですか?

実際、nbehaveテストを実行し、それらをビルドサーバーと統合するためのヒントをいただければ幸いです。

たぶん良い選択肢がありますか?