RoR を使用して作成している自分の小さなプロジェクトがあり、小規模から中規模の負荷を計画しています。
間違いなく、私は BDD と TDD (正確には Cucumber と RSpec ですが、TestUnit の経験もあります) から始めました。気に入っていますが、これは私自身のプロジェクトであり、ややスタートアップなので、多くのことを変更しています。要件、物事がどのように機能し、どのように見えるべきかについての多くのアイデア。そのため、一般的なケースだけを取り上げたとしても、常に BDD と TDD を使用してコーディングするのは時間がかかりすぎます。
私は何をすべきか？テストを書くよりも、しっかりとした基盤ができて実稼働の時期になるまで、生産性のために BDD と TDD を犠牲にする必要がありますか?
それらを今すぐ書くべきですが、できるだけ最小限に抑えますか? 今のところ、RSpec だけを作成し、Cucumber のことは忘れるべきですか? それとも、TestUnit が最も重要であり、他のすべてが変更される可能性があるため、今のところモデルをテストするための TestUnit だけでしょうか?
前もって感謝します！
6 に答える
3
これは政治的に正しい答えではなく、純粋主義者を動揺させると確信しています。小規模で急速に変化するプロジェクトの場合は、コードを記述して TDD と BDD の手順をスキップする方がよいでしょう。そうしないと、完了が大幅に遅れます。これは常に従うべき規則ではありませんが、プロジェクトの要件を理解していると判断した場合は、コードを書くことに罪悪感を感じないでください。
于 2013-03-16T00:07:10.343 に答える
2
BDD/TDDを使用すると生産性が向上する可能性があります。要件は頻繁に変更されるとおっしゃっていますが、テストケースなどの変更/作成は、実際のコードを作成してから破棄し、要件が変更されるたびに新しいコードを作成するよりも柔軟で迅速である可能性があります。おそらく、この方法でそれを行うことは、作成したい変更を精査するための一種のフィルター/レイヤーとして機能します。実装に時間を費やす前に、物事がうまくいくかどうかを知るのに役立つかもしれません。もちろん、それを実装すると、TDDの利点が得られ、正確性を確認するためのテストスイートがすでに用意されています。
于 2013-03-15T23:56:33.820 に答える
2
個人的には、機能、設計、実装などを定義するためだけに反復する場合は、テストを軽視する傾向があります。
とはいえ、その部分が終わったら、通常は開発スパイクを捨てて、T/BDD を使用して成果物を作成します。
于 2013-03-16T00:12:35.037 に答える
0
要件が大きく変化しているという理由だけで、TDD (おそらく BDD ではない) を使用したいと思います。TDD により、リファクタリング可能な設計とコードベースが可能になり、その結果、変更が容易になります。プロジェクトの過程で (たとえ 1 週間か 2 週間という短い期間であっても)、TDD + リファクタリングを使用すると、使用しなかった場合よりも実際に速く動くようになります。
于 2013-03-16T09:51:49.930 に答える
0
そのため、一般的なケースだけを取り上げたとしても、常に BDD と TDD を使用してコーディングするのは時間がかかりすぎます。
私は常にTDDを使用してコーディング速度を向上させているようです。テストの実行中に「ばかげたコーディング バグ」を見つけ、単体テストを行わない場合よりも早く根本原因を見つけます。
BDD の場合、要件がオーバーホールされる傾向にある場合、船がより統一された方向に向けて出航するまで、要件のテストを遅らせることが想像できます。
于 2013-03-16T08:08:05.500 に答える