tdd - TDD。いつ次に進むことができますか？

Question

TDDを実行するとき、「このクラス/機能には十分なテストです」と伝えるにはどうすればよいですか?

つまり、すべてのエッジケースのテストを完了したと言えるのはいつですか?

score 13 · Accepted Answer

テスト駆動開発では、テストするコードを作成する前にテストを作成します。コードを記述してテストに合格したら、次は別のテストを記述します。TDDに正しく従えば、必要なことをすべて実行するコードを作成したら、十分なテストを作成できます。

エッジケースについては、メソッドのパラメータを検証するなどの例を見てみましょう。コードにパラメーターを追加する前に、コードが各ケースを正しく処理することを確認するテストを作成します。次に、パラメーターと関連するロジックを追加して、テストに合格することを確認できます。より多くのエッジケースを考えれば、さらにテストを追加できます。

一度に1ステップずつ実行することで、コードの記述が終了したときにエッジケースについて心配する必要がなくなります。これは、すべてのテストを既に記述しているためです。もちろん、人為的エラーは常に発生し、何かを見逃す可能性があります...そのような状況が発生した場合は、別のテストを追加してからコードを修正します。

score 9 · Accepted Answer

Kent Beck のアドバイスは、恐怖が退屈に変わるまでテストを書くことです。つまり、適切なレベルの恐怖から始めると仮定して、何かが壊れるという恐怖がなくなるまで.

score 3 · Accepted Answer

あるレベルでは、それはの直感です

「今考えられるすべての問題をテストで検出できると確信していますか?」

別のレベルでは、満たさなければならない一連のユーザー要件またはシステム要件がすでにあるので、そこでやめることができます。

私はコードカバレッジを使用して、自分の TDD プロセスに従わなかったかどうかを教えたり、削除できるコードを見つけたりしていますが、コードカバレッジを停止時期を知るための有用な方法とは考えていません。コードカバレッジは 100% である可能性がありますが、要件を含めるのを忘れた場合は、それで終わりではありません。

おそらく、TDD についての誤解は、テストを行う前にすべてを把握しておく必要があるというものです。TDD プロセスの結果として得られるテストはパンくずリストのようなものであるため、これは誤った方向に進んでいます。あなたは過去に何がテストされたかを知っており、ある程度は導くことができますが、次に何をすべきかは教えてくれません.

TDD は進化のプロセスと考えることができると思います。つまり、最初の設計と一連のテストから始めます。本番環境でコードがボロボロになると、さらにテストを追加し、それらのテストに合格するコードを追加します。ここにテストを追加し、そこにテストを追加するたびに、TDD も実行しますが、それほどコストはかかりません。最初の一連のテストを作成したときは、これらのケースが存在することを知りませんでしたが、今では知識を得て、ボタンを押すだけでそれらの問題をチェックできます。これが TDD の大きな力であり、私が TDD を強く支持する理由の 1 つです。

score 2 · Accepted Answer

テストは、必要なものを正確に記述する方法です。テストを追加すると、必要なものの範囲が拡大したり、必要なものの詳細が追加されたりします。

あなたが望むもの、またはあなたが望むものへの改良をこれ以上考えることができないならば、それから他のものに移ってください。いつでも後で戻ってくることができます。

score 2 · Accepted Answer

まあ、意図したとおりに機能しない失敗例がこれ以上思いつかないとき。

TDDの一部は、実装したいもののリストと現在の実装の問題を保持することです...そのリストがなくなると、基本的に完了です....

また、バグや実装に関する新しい問題を発見した場合は、いつでも戻ってテストを追加できることを忘れないでください。

score 2 · Accepted Answer

その常識、完璧な答えはありません。TDD の目標は、恐怖を取り除くことです。十分にテストした自信がある場合は、続けてください...

後でバグを見つけた場合は、最初にテストを作成してバグを再現し、それを修正することを忘れないでください。そうすれば、将来の変更で再びバグが発生するのを防ぐことができます。

一部の人々は、X パーセントのカバレッジがないと文句を言います.... 役に立たないテストもあります。100% のカバレッジは、コードを壊す可能性のあるすべてをテストすることを意味するわけではありません。それ！

score 2 · Accepted Answer

TDD でのテストは、仕様をカバーするためのものであり、実際には仕様の代わりになる可能性があります。TDD では、テストはコードをカバーすることではありません。コードが仕様をカバーしていない場合、コードはテストに失敗するため、コードが仕様をカバーしていることを確認します。余分なコードは関係ありません。

したがって、テストがあなたまたは利害関係者が持っているすべての期待を説明しているように見える場合、十分なテストがあります。

score 1 · Accepted Answer

他のコメントの多くは頭に釘を打ちました。テストカバレッジを考慮して、作成したコードに自信がありますか？コードが進化しても、テストはそれを適切にカバーしていますか？テストでは、テスト対象のコンポーネントの意図された動作と機能をキャプチャしていますか？

幸せな媒体がなければなりません。テストケースを追加するにつれて、エッジケースと見なされるものが絶えず変化するため、テストが脆弱になる可能性があります。以前の提案の多くに従って、考えられるすべてのものを前もって取得し、ソフトウェアの成長に合わせて新しいテストを追加すると非常に役立ちます。この種の有機的な成長は、事前にすべての努力をしなくてもテストを成長させるのに役立ちます。

私はうそをつくつもりはありませんが、追加のテストを書くために戻ったときにしばしば怠惰になります。0コードを含むプロパティ、または気にしないデフォルトのコンストラクターを見逃す可能性があります。プロセスについて完全に分析されていない場合は、重要度が低い領域（100％コードカバレッジの神話）で時間を節約できる場合があります。

最終的な目標は、一流の製品をドアから出すことであり、テストを自殺することではないことを覚えておく必要があります。あなたが何かを逃しているような腸の感覚を持っているなら、あなたはあなたが持っている可能性があり、あなたはさらにテストを追加する必要があります。

幸運と幸せなコーディング。

score 1 · Accepted Answer

理論的には、考えられるすべての入力の組み合わせをカバーし、出力が正しいことをテストする必要がありますが、それだけの価値がない場合もあります。

score 1 · Accepted Answer

Alberto Savoiaは次のように述べています。テストについて考える良い方法だと思います: エッジケースを行っているかどうかを尋ねたり、予期しないパラメーターを渡したりします。テストの品質を向上させる良い方法は、ペア (特にテスター) と協力して、より多くのテストケースについて支援を受けることです。異なる視点を持っているため、テスターとペアを組むことは良いことです。

もちろん、何らかのツールを使用してミューテーションテストを実行し、テストの信頼性を高めることもできます。私はJesterを使用しており、テストとその記述方法の両方が改善されています。そのようなものを使用することを検討してください。

敬具

score 1 · Accepted Answer

アジャイル/XP の世界のどこかで何かを見逃していたのかもしれませんが、プロセスについての私の理解は、開発者と顧客がテストを Feature の一部として指定するということでした。これにより、テストケースをより正式な要件ドキュメントの代わりにすることができ、機能のユースケースを特定するのに役立ちます。これらのすべてのテストに合格すると、テストとコーディングが完了します...さらに、考えられるその他のエッジケース途中の

score 0 · Accepted Answer

EMMA ( http://emma.sourceforge.net/ ) やその Eclipse プラグイン EclEmma ( http://www.eclemma.org/ ) などのテストカバレッジツールをいつでも使用できます。一部の開発者は、100% のテストカバレッジが価値のある目標であると考えています。他の人は同意しません。

score 0 · Accepted Answer

何かが失敗する可能性があるという理由の範囲内で、あらゆる方法を考え出すようにしてください。Null 値、範囲外の値など。簡単に何も思いつかなくなったら、別のことに進みます。

途中で新しいバグを見つけたり、方法を思いついたりした場合は、テストを追加してください。

コードカバレッジについてではありません。コードは「十分にテスト」されるずっと前に「カバー」されるため、これは危険な指標です。

tdd - TDD。いつ次に進むことができますか？

13 に答える 13

Related

Reference