この質問への回答を読んでテスト駆動開発の欠点? TDDとは何か、どのように実施すべきかについて、誤解が多い印象を受けました。ここでこれらの問題に対処することが役立つ場合があります。
1216 次
6 に答える
13
受け入れられた答えは最も弱いものの1つであり（テスト駆動開発の欠点？）、最も更新された答えは、指定されたテストを上書きしている可能性のある誰かのにおいがします。
多大な時間の投資：単純なケースでは実際の実装の約20％が失われますが、複雑なケースではさらに多くの損失が発生します。
TDDは投資です。TDDに完全に夢中になったら、失った時間はごくわずかであり、維持時間に関しては、失った時間は埋め合わせ以上のものであることがわかりました。
複雑なケースの場合、テストケースの計算が難しいため、そのような場合は、最も単純なケースの単体テストではなく、デバッグバージョン/テスト実行で並行して実行される自動参照コードを使用することをお勧めします。
テストが非常に複雑になっている場合は、設計を確認する時期かもしれません。TDDは、より小さく、より複雑でないコード単位が連携して機能するように導きます。
設計が最初は明確でなく、進むにつれて進化することがあります。これにより、テストをやり直す必要があり、大きな時間の損失が発生します。この場合、設計をある程度理解するまで単体テストを延期することをお勧めします。
これはそれらすべての最悪のポイントです！TDDは実際には「テスト駆動設計」である必要があります。TDDは設計に関するものであり、テストに関するものではありません。TDDの利点の価値を完全に実現するには、テストから設計をおもちゃで駆り立てる必要があります。したがって、この点が示唆するように、テストに合格するために本番コードをやり直す必要があります。その逆ではありません。
現在最も改造されているもの：テスト駆動開発のデメリット？
多数のテストがある場合、システムを変更すると、変更によって無効になったテストに応じて、テストの一部またはすべてを書き直す必要がある場合があります。これにより、比較的迅速な変更が非常に時間のかかる変更に変わる可能性があります。
受け入れられた回答の最初のポイントと同様に、これはテストの仕様を超えており、TDDプロセスの一般的な理解が不足しているようです。変更を加えるときは、テストから始めてください。新しいコードが何をすべきかについてのテストを変更し、変更を加えます。その変更が他のテストを壊す場合、あなたのテストは彼らがすることになっていることをしていて、失敗します。私にとって、ユニットテストは失敗するように設計されているため、REDステージが最初であり、見逃してはなりません。
于 2008-09-16T13:42:35.597 に答える
5
IMHO TDD に関する最大の誤解は、テストの作成とリファクタリングに費やす時間が失われるということです。「ええ、テスト スイートは素晴らしいものですが、コーディングするだけで、機能ははるかに速く完成するでしょう」というような考え方になります。
適切に実行すると、テストの作成と保守に費やす時間が、デバッグと回帰の修正に費やされない時間で、プロジェクトの存続期間にわたって何度も節約されます。テストのコストは前払いで、ペイオフは時間の経過とともに発生するため、見落としがちです。
その他の大きな誤解には、TDD が設計プロセスに与える影響を無視していることや、「苦痛なテスト」が深刻なコード臭であり、早急に修正する必要があることを認識していないことが含まれます。
于 2008-09-16T13:48:14.570 に答える
1
多くの人が、どのテストが実際に TDD に役立つかを誤解しています。小規模な単体テストではなく大規模な受け入れテストを作成した後、テストの維持に多大な時間を費やし、TDD が機能しないと結論付ける人がいます。BDD の人々は、テストという言葉の使用を完全に避けることに意味があると思います。
もう 1 つの極端な例は、人々が受け入れテストをやめて、単体テストを行ったためにコードがテストされたと考えていることです。これも、単体テストの機能に対する誤解です。なんらかの受け入れテストが必要です。
于 2008-09-16T13:37:29.010 に答える
0
私がよく目にする誤解は、TDD が良い結果を保証するというものです。
多くの場合、テストは欠陥のある要件から書き留められます。したがって、開発者は、ユーザーが期待することを行わない製品を作成します。私の意見では、TDD の鍵は、ユーザーと協力して要件を定義し、ユーザーの期待を管理することです。
于 2008-09-16T13:29:07.360 に答える
0
これらは、私の意見では非常に物議を醸しているため、誤解されやすい問題です。
私の経験では、最大の利点は、テストの作成に多くの時間を費やす代わりに、はるかに優れたコードを作成できることです。したがって、高品質を必要とするプロジェクトには本当に価値がありますが、品質がそれほど重視されない他のサイトでは、余分な時間は努力する価値がありません.
人々は、機能の主要なサブセットのみをテストする必要があると考えているようですが、それは実際には間違っています。リファクタリング後にテストが有効になるように、すべてをテストする必要があります。
TDD の大きな欠点は、不完全なテストによってもたらされる誤った安心感です。デプロイをトリガーするには単体テストで十分だと人々が想定したために、サイトがダウンするのを見てきました。
TDD を行うためにフレームワークをモックする必要はありません。これは、いくつかのケースをより簡単な方法でテストするための単なるツールです。ただし、最適な単体テストはスタックの上位で起動され、コード内のレイヤーにとらわれない必要があります。このコンテキストでは、一度に 1 つのレイヤーをテストしても意味がありません。
于 2008-09-16T13:35:37.830 に答える
0
ポットに別の答えを投げ込むだけです。
最も一般的な誤解の 1 つは、コードが固定されているというものです。私はこのコードを持っています。いったいどうやってそれをテストするのでしょうか? テストを書くのが難しい場合は、次の質問をする必要があります: テストを簡単にするために、このコードをどのように変更できますか?
どうして..？
簡単にテストできるコードの種類は次のとおりです。
- モジュラー - 各メソッドは 1 つのことを行います。
- パラメータ化 - 各メソッドは必要なものをすべて受け入れ、必要なものをすべて出力します。
- 適切に指定されている - 各メソッドは、それ以上でもそれ以下でもなく、本来あるべきことを正確に実行します。
このようなコードを書くと、テストは面倒です。興味深いことに、テストしやすいコードは、偶然にもより優れたコードであるということです。
読みやすく、テストしやすく、理解しやすく、デバッグしやすいという点で優れています。これが、TDD がしばしば設計課題として説明される理由です。
于 2011-04-12T08:55:31.463 に答える