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

YahtzeeゲームのTDDスタイルを書いているとしましょう。5つのサイコロのセットがフルハウスかどうかを判断するコードの一部をテストします。私の知る限り、TDDを行うときは、次の原則に従います。 最初にテストを書く 可能な限り簡単なことを書く リファインとリファクタリング したがって、最初のテストは次のようになります。 public void Returns_true_when_roll_is_full_house() { FullHouseTester sut = new FullHouseTester(); var actual = sut.IsFullHouse(1, 1, 1, 2, 2); Assert.IsTrue(actual); } 「可能な限り最も簡単なものを書く」に従っている場合、次のようにIsFullHouseメソッドを記述する必要があります。 public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5) { if (roll1 == 1 && roll2 == 1 && roll3 == 1 …

36 unit-testing  tdd 

コーディングは初めてではありません。私は今15年以上にわたって（まじめに）コーディングしてきました。私はいつも自分のコードに対していくつかのテストを行ってきました。ただし、ここ数か月にわたって、Ruby on Railsを使用してテスト駆動設計/開発（TDD）を学んでいます。これまでのところ、私は利益を見ていません。 いくつかのテストを書くことにはいくつかの利点がありますが、ごくわずかです。そして、最初にテストを書くというアイデアは好きですが、実際のコードをデバッグするよりも、テストのデバッグに時間を費やして、自分の本当の意味を伝えるようにします。これはおそらく、テストコードがテストするコードよりもかなり複雑になることが多いためです。これが利用可能なツール（この場合はRSpec）に不慣れであることを願っています。 ただし、この時点で、失望のレベルと期待を裏切るパフォーマンスの欠如が許容できないレベルを超えています。これまでのところ、TDDから私が見ている唯一の価値は、他のプロジェクト/ファイルのテンプレートとして機能するRSpecファイルの成長するライブラリです。これは実際のプロジェクトコードファイルよりもはるかに有用ではなく、おそらくあまり有用ではありません。 入手可能な文献を読むと、TDDは前もって大きな時間を費やしているように見えますが、最終的には報われます。私はただ疑問に思っています、実世界の例はありますか？この大きな不満は現実の世界で報われるのでしょうか？ ここのどこかでこの質問を見逃さなかったことを本当に願っています。検索しましたが、この時点ですべての質問/回答は数年前のものです。TDDについて悪いことを言う開発者を見つけたのはめったにありませんでした。しかし、特定の実世界の例を指し示している人はいないようです。2011年にコードをデバッグしている人は、完全な単体テストスイートを用意してくれてありがとう（コメントは2008年に作成されたと思います）という答えを1つ読みました。 だから、私は、これらすべての年月の後に、ペイオフが本物であることを示す例が最終的にありますか？TDDを使用して設計/開発され、単体テストの完全なセットを持ち、実際に見返りを感じたコードを実際に継承または戻した人はいますか？それとも、テストが何をテストしているのか（そしてなぜそれが重要だったのか）を把握しようとして非常に多くの時間を費やしていたので、コードを掘り下げて掘り下げましたか？

36 ruby-on-rails  unit-testing  tdd 

TDDを実行して単体テストを作成する場合、テストする「実装」コードの最初の反復を作成するときに、「チート」という衝動にどのように抵抗しますか。 例： 数値の階乗を計算する必要があります。次のような単体テスト（MSTestを使用）から始めます。 [TestClass] public class CalculateFactorialTests { [TestMethod] public void CalculateFactorial_5_input_returns_120() { // Arrange var myMath = new MyMath(); // Act long output = myMath.CalculateFactorial(5); // Assert Assert.AreEqual(120, output); } } このコードを実行すると、CalculateFactorialメソッドが存在しないため失敗します。そこで、テスト対象のメソッドを実装するためのコードの最初の反復を記述し、テストに合格するために必要な最小限の コードを記述します。 実は、私は次のように書き続けたいと思っています。 public class MyMath { public long CalculateFactorial(long input) { return 120; } } これは、技術的には、それで正しいです、本当に最低限のコードをするために必要とされている特定のテストパス作るそれは本当にさえいないので、それは明確に「チート」ですが、（緑行く）を試みる階乗を計算する機能を実行します。もちろん、今では、リファクタリングの部分は、実装の真のリファクタリングではなく、「正しい機能の記述」の演習になります。明らかに、異なるパラメーターで追加のテストを追加すると失敗し、リファクタリングが強制されますが、その1つのテストから開始する必要があります。 だから、私の質問は、「テストに合格するための最小限のコードを書く」ことと、機能を維持しつつ、実際に達成しようとしていることの精神とのバランスをどのように得るかということです。

36 unit-testing  tdd 

最初に単体テストを作成してからコードの作成を開始することをお勧めします。しかし、私にとっては、逆の方がはるかに快適だと感じています-実際にコードを書いた後、より明確になったと感じているので、コードを書いてからユニットテストを書いてください。コードを作成してからテストを作成すると、テスト可能なデザインの作成に専念しても、コードを少し変更してテスト可能にする必要がある場合があります。一方、テストを作成してからコードを作成すると、コードが形成されるときにテストが頻繁に変更されます。 テストの作成を開始してからコーディングに進むための多くの推奨事項がありますが、逆にコードを作成してから単体テストを行う場合のデメリットは何ですか？

33 testing  unit-testing  code-quality  tdd 

テスト駆動開発。好きです。 ただし、テストの作成にはオーバーヘッドが必要です。したがって、TDDをコードベース全体で普遍的に使用する必要がありますか、それともTDDが高いROIを提供する領域と、ROIが非常に低いためフォローする価値がない領域があります。

31 development-process  tdd 

テスト駆動開発（TDD）では、最適ではないソリューションから開始し、テストケースを追加してリファクタリングすることにより、より良いソリューションを繰り返し生成します。ステップは小さいと想定されています。つまり、新しいソリューションはそれぞれ前のソリューションの近くにあることになります。 これは、勾配降下法やローカル検索などの数学的なローカル最適化方法に似ています。このような方法のよく知られた制限は、グローバルな最適値、または許容可能なローカルな最適値を見つけることを保証しないことです。開始点が悪い解の大きな領域によってすべての許容可能な解から分離されている場合、そこに到達することは不可能であり、メソッドは失敗します。 より具体的に言うと、いくつかのテストケースを実装した後、次のテストケースではまったく異なるアプローチが必要になるというシナリオを考えています。前の作業を破棄して、最初からやり直す必要があります。 この考え方は、TDDだけでなく、小さなステップで進行するすべてのアジャイルメソッドに実際に適用できます。この提案されたTDDとローカル最適化の類推には重大な欠陥がありますか？

30 agile  development-process  tdd  development-methodologies 

TDDユニットルールのルールによれば、製品コードの前に記述されていますが、具体的な（モックではない）ワイヤードオブジェクト間の相互作用を実行する統合テストについてはどうでしょうか。 「配線」をテストするためだけに、単体テストの前に作成するか、製品コードの後に​​作成する必要がありますか？ 私は、受け入れテストや機能テストではなく、低レベルの統合テストについて話していることに注意してください。

30 tdd  integration-tests 

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

30 tdd  bdd 

私は、一部の人々がテスト駆動開発の大規模な支持者であることを知っています。私は過去に単体テストを使用しましたが、簡単にテストできる操作、またはおそらく正しいと思われる操作をテストするためだけに使用しました。完全またはほぼ完全なコードカバレッジは、多くの時間がかかるようです。 テスト駆動開発を使用するプロジェクトは何ですか？特定のサイズを超えるプロジェクトにのみ使用しますか？ 私はそれを使用する必要がありますか？信じさせて！

30 programming-practices  unit-testing  tdd 

他のキャラクターやそのようなものを攻撃するキャラクターでロールゲームの開発を始めたとしましょう。 TDDを適用して、Character.receiveAttack(Int)メソッド内のロジックをテストするテストケースを作成します。このようなもの： @Test fun healthIsReducedWhenCharacterIsAttacked() { val c = Character(100) //arg is the health c.receiveAttack(50) //arg is the suffered attack damage assertThat(c.health, is(50)); } メソッドをテストreceiveAttackする10のメソッドがあるとします。次に、メソッドCharacter.attack(Character)（メソッドを呼び出すreceiveAttack）を追加し、TDDサイクルでテストした後、決定するCharacter.receiveAttack(Int)必要がありますprivate。 以前の10個のテストケースはどうなりますか？それらを削除する必要がありますか？メソッドを保持する必要publicがあります（そうは思わない）。 この質問は、プライベートメソッドをテストする方法ではなく、TDDを適用する際の再設計後にそれらを処理する方法に関するものです。

29 object-oriented-design  tdd 

バグを修正する場合、最初に特定のバグで失敗するテストを記述し、次にテストが合格するまでコードを修正することをお勧めします。これはTDDのプラクティスに従っており、良いプラクティスであると想定されていますが、実装に非常に近い不可解なテストを作成する傾向があることに気付きました。 たとえば、ジョブが送信され、特定の状態に到達し、中止され、再試行されたときに問題が発生しました。このバグを再現するために、スレッド同期、多くのモックなどを含む大規模なテストが作成されました...それは仕事をしましたが、コードをリファクタリングしているので、このマンモスを削除するだけで非常に魅力的です新しいデザインに合わせるには、本当に多くの作業が（再び）必要になります。そして、1つの特定のケースで1つの小さな機能をテストするだけです。 したがって、私の質問：再現が難しいバグをどのようにテストしますか？実装をテストし、リファクタリングと可読性を損なうものを作成しないようにするにはどうすればよいですか？

29 testing  tdd 

別の質問で、TDDの問題の1つは、リファクタリング中およびリファクタリング後にテストスイートをコードベースと同期させることであることが明らかになりました。 今、私はリファクタリングの大ファンです。TDDをやめるつもりはありません。しかし、マイナーなリファクタリングが多くのテストの失敗につながるような方法で書かれたテストの問題も経験しました。 リファクタリング時にテストが中断しないようにするにはどうすればよいですか？ テストを「より良い」と書いていますか？もしそうなら、あなたは何を探すべきですか？ 特定の種類のリファクタリングを避けていますか？ テストリファクタリングツールはありますか？ 編集：質問の意味を尋ねる新しい質問を書きました（ただし、これは興味深いバリエーションとして残しました）。

29 development-process  tdd  refactoring 

TDDを使用して開発する予定の新しい（非常に大きな）プロジェクトが開始されました。 TDDのアイデアは失敗しました（多くのビジネス上の理由とビジネス以外の理由）が、今は会話があります-いずれにしてもユニットテストを書くべきかどうか。私の友人は、TDDを使用せずに単体テストを書くことには意味がない（またはゼロに近い）ため、統合テストのみに焦点を合わせる必要があると言います。単純な単体テストを記述することには、コードの将来性をより高めるために、まだある程度の意味があると私は反対に思います。どう思いますか？ 追加：これは>> this question <<の複製ではないと思います-UTとTDDの違いを理解しています。私の質問は違いではなく、TDDなしで単体テストを書く感覚です。

28 unit-testing  tdd 

Ruby on Railsで最初の実際のプロジェクトを開始し、TDDテストの作成を強制します。テストを書くことに本当の利点はないと思いますが、それは非常に重要だと思われるので、試してみます。 静的ページを含むアプリケーションのすべての部分をテストする必要がありますか？

28 testing  tdd 

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

28 code-quality  tdd  bdd