TDDネガティブエクスペリエンス[終了]

TDD体験のマイナス面は何ですか？赤ちゃんのステップ（テストをグリーンにするための最も簡単な修正）が迷惑で役に立たないと感じますか？価値のないテストを見つけますか（テストは最初は意味がありますが、最終的な実装では他のテストと同じロジックをチェックします）メンテナンスが重要ですか？等

上記の質問は、TDDの経験中に私が不快に思うことに関するものです。だから私は他の開発者が同じような感情を持っているかどうか、彼らは彼らについてどう思うか興味があります。

TDDのネガティブな側面を説明する記事へのリンクに感謝します（Googleはポジティブで熱狂的な記事でいっぱいです）。

「アジャイル」バナーの下にあるすべてのものと同様に、TDDは理論上は良いように聞こえますが、実際にはどれほど良いかは明確ではありません（また、ほとんどの「アジャイル」のように、そうしないと言われますそれのように、あなたはそれを間違っています）。

TDDの定義は明確にエッチングされていません。KentBeckのような人は、1行のコードの前に非コンパイルテストを作成し、失敗したテストに合格するためにすべてのコード行を作成することを要求します。最前線の設計は最小限で、すべてが推進されますテストによって。うまくいきません。その方法論を使用して開発された大規模なエンタープライズアプリを見てきましたが、これが私のキャリアで見られる最悪のコードであることを望みます（それほど遠くないでしょう。そして、才能のある開発者がそれに取り組んでいたにもかかわらずです）。私が見てきたことから、関数呼び出しが発生すること、変数がnullでモックフレームワークが徹底的なワークアウト（whoop-de-whoop）を取得したときに例外がスローされることを主に検証する非常に多くのよく考えられていないテストになります; 本番コードはこれらのテストに大きく結びついており、絶え間なく簡単なリファクタリングの夢は現れません。実際、すべてのテストが壊れるので、悪いコードを修正する可能性はさらに低くなります。

逆に、TDDは、計画段階の一部として、アーキテクチャ設計と並行して、テストを事前に高レベルで設計することを意味すると人々が主張するのを聞いたことがあります。これらのテストは、より多くの情報が利用可能になると開発中に変更される可能性がありますが、慎重に検討され、コードが実際に何をすべきかについての良いガイドを提供します。私にはそれは完全に理にかなっています。

この（Clojureの著者）Rich Hickeyのインタビューには以下が含まれています。私は100％思いやりがあります：

寿命は短く、1日の時間数は限られています。ですから、私たちは自分の時間をどのように過ごすかについて選択をしなければなりません。テストの作成に費やすなら、それは私たちが何か他のことをするのに費やしていない時間です。量と質の両方で結果を最大化するために、私たち一人一人が最善の時間を費やすことを評価する必要があります。テストの作成に時間の50％を費やすことで結果が最大になると人々が思う場合は、大丈夫です。それは私には当てはまらないと思います。むしろ、自分の問題について考える時間を費やしたいと思います。私にとって、これは他の時間の使用よりも優れたソリューションを生み出し、欠陥が少ないと確信しています。完全なテストスイートを備えた不適切なデザインは、依然として不適切なデザインです。

Coders at Workの書籍インタビューのDonald Knuthからの別の同様の声明は、ここからコピーアンドペーストされています。

Seibel：実際の仕事と言えば、The Art of Computer Programmingの作業中に、10年休みになったものを組版システムTeXを書くために取りました。TeXの最初のバージョンは、コンピューターから完全に離れて作成したことを理解しています。

Knuth：1977年と78年にTeXを最初に書いたとき、もちろん文芸的なプログラミングはありませんでしたが、構造化プログラミングはしました。筆記用の大きなノートに鉛筆で書きました。6か月後、プロジェクト全体を終えた後、コンピューターに入力し始めました。そして、'77年の10月にプログラムの作成を開始したときに、'78年の3月にデバッグを行いました。そのためのコードはスタンフォードのアーカイブにあります-それはすべて鉛筆です-そしてもちろん、私はそれがどうあるべきかを学んだときに戻ってサブルーチンを変更します。これは第一世代のシステムだったので、多くの異なるアーキテクチャが可能であり、しばらくの間それを使って何があったのかを知るまで捨てなければなりませんでした。そして、これは鶏と卵の問題でした。フォントができるまでタイプセットすることはできませんでしたが、タイプセットできるようになるまでフォントを手に入れることはできませんでした。しかし、構造化プログラミングにより、不変式の考え方と、理解できるブラックボックスの作成方法がわかりました。そのため、最終的にデバッグするときにコードが機能するという自信がありました。何かをテストする前に6か月待てば、多くの時間を節約できると感じました。コードがほぼ正しいという自信がありました。

Seibel：足場とスタブを構築して不完全なコードをテストするのに時間を費やさないので、時間を節約できますか？

クヌース：そう。

TDDでのネガティブな経験は初めてでした。TDDは私にとって素晴らしいサウンドでした。私は長年QAを行ってきましたが、それでも心の中で恐怖は新鮮でした。バグをビルドする前にすべてのバグをつぶしたかったのです。残念ながら、TDDを使用しても、適切なテストを作成できるとは限りません。実際、私の最初の傾向は、簡単なコードを生成する簡単なテストを書くことでした。抽象化がほとんど含まれていない本当にシンプルなコード。クラス内部と絡み合った本当に簡単なテスト。そして、数千のちょっとしたテストを実施したら、コードをリファクタリングして非常に重要なドメインコンセプトXを使用するためにテストを数百回変更しなければならないときに、速く動いているとは思わないでしょう。

私に光が当たりました-TDDはテストスキルではありません。それは設計スキルです。実践的で、設計の方向性を常に意識して、優れたシンプルで実行可能なコードに導くことができます。コードカバレッジのためにテストを記述する場合は、脆弱なテストを作成します。抽象化の設計に役立つテストを作成している場合、トップダウンコードを作成するより厳密な方法にすぎません。最初に呼び出し元の視点からコードを見ることができます。これにより、クラスの内部をその外側のエッジにミラーリングするのではなく、彼の生活を楽にすることができます。

TDDは便利だと思いますが、私はそれについて独断的ではありません。それらの「価値のないテスト」がメンテナンスを困難にしている場合-それらを削除してください！私はテストを他のコードと同じように扱います。リファクタリングして簡単にできる場合は、それを実行してください！

個人的には見ていませんが、一部の場所ではコードカバレッジとテストカウントを追跡していると聞きました。したがって、メトリックの収集がTDDの副作用である場合、それもマイナスであると考えられます。私は熱心に1000行のコードを削除し、それが20のテストを廃止し、コードカバレッジ％を落とすなら、まあまあです。

私はここで手足に出て、それが文字通り時間の儀式的な浪費であることを残忍な誠実さで宣言します。（ほとんどの状況で。）

ユニットテストに関する本を購入し、TDDについても説明しました。UTの利点には同意しますが、TDDを約100時間試した後、さまざまな理由でそれをあきらめました。私はここにクロスポストのようなものですが、TDD：

1. 実際のドキュメントよりも優れたドキュメントではありません。
2. バグやリグレッションをキャッチしません。
3. 関数型プログラミングと構成可能性の概念を適用した場合、設計が最終的に改善されるわけではありません。
4. コードレビューを行ったり、ドキュメントや仕様を磨いたりするのに費やすことができる時間です。
5. マネージャーが何百もの緑色のアイコンのリストを見たときに、マネージャーに誤った安心感を与えます。
6. 入出力マッピングが制限されたアルゴリズムの実装の生産性が向上します。
7. TDDの結果、自分が何をしているかを知っているかもしれないという点で不器用ですが、なぜそれがうまく機能するのか、なぜデザインがうまくいくのかについては理解していません。

もう1つの懸念は、TDDを使用して正常に実行する必要のある議論の完成度です。プロジェクトの最初からチームの全員がTDDを永続的に行わないと、苦しむだけだと言う人もいます。他の人は、この本によってTDDを実行することはないと主張しています。これらの両方が真である場合、TDD実践者は、それを認識しているかどうかにかかわらず、苦しんでいることになります。

もちろん、TDDのような方法で物事を行うことで、TDDで簡単に作業できる設計にたどり着くと主張されている場合、それを達成するためのより迅速な方法があります。つまり、実際に構成可能性。そこには多くのリソースがあり、厳密な数学的理論もたくさんあります（主に関数型プログラミングだけでなく、他の分野でも）。すべてのTDD時間を学習に費やしてみませんか？

文化的には、TDDは儀式的な慣習であるという症状を示しています。それは罪悪感に乗っています。理解よりも手順を奨励します。たくさんの教義とスローガンがあります（「偽造するまで」は、客観的に見ると非常に憂慮すべきです）。ウィキペディアの「儀式」という言葉の定義は、実際にはかなり適切です。

心理学では、「儀式」という用語は、不安を中和または防止するために人が体系的に使用する反復的な行動の技術的な意味で使用されることがあります。それは強迫性障害の症状です。

加えて、私が気づいたTDDに関するもう1つの懸念は次のとおりです。

TDDは、開発チームの品質コードからテストケースとコードカバレッジへの不注意なシフトを引き起こします！私は個人的にTDDが好きではありませんでした。TDDは創造性を低下させ、ソフトウェア開発を退屈な機械プロセスにしています。ユニットテストケースは、慎重に使用すると便利ですが、ソフトウェア開発の目標を処理すると負担になります。

私はマネージャーであり、かつてTDDに夢中になった技術的に退屈な人を知っています。彼にとって非常に不思議なことであり、保守性の低いコードで貧弱なアーキテクチャのソフトウェアのすべての問題に魔法の解決策をもたらすと信じていました。そのプロジェクトに何が起こったのかは言うまでもありません。彼のテストケースはすべて緑でしたが、彼の手で惨めに失敗しました。TDDは、「私のケースの99/100は環境に優しい」などの統計情報の取得に役立ち、品質を評価したり、デザインの改善を提案したりすることができないため、彼の強迫観念の理由になったと思います。

私の主な否定的な経験は、TDDを使用して、テストがない、または非常に基本的な統合テストがない別のプログラマーのコードを編集することです。機能を追加したり、コードの問題を修正したりするとき; 最初にテストを書くことをお勧めします（TDDの方法）。残念ながら、コードは密結合されているため、多くのリファクタリングを行わないとテストできません。

とにかくリファクタリングは素晴らしい練習ですが、コードをテスト可能な状態にするために必要です。そして、このステップの後、私の変更が何かを壊したかどうかを確認するためのチェックとバランスがありません。アプリケーションを実行し、すべてのユースケースを調べる必要はありません。

一方、TDDプロジェクトへの機能の追加/バグの修正は非常に簡単になります。本質的に、TDDで記述されたコードは、通常、作業する小さな部分と完全に分離されています。

いずれにしても、TDDはガイドラインです。最大の効果が得られると思われるところまでそれに従ってください。適切なテストカバレッジと分離されたコード、適切に記述されたコード。

システムの設計に関しては、テストに依存しすぎることがあるという経験をしました。基本的に、実装の詳細についてはあまりにも低すぎて、一歩進んで全体像を見ることができません。これにより、多くの場合、不必要に複雑な設計になります。私はコードをリファクタリングすることになっていることを知っていますが、時には一歩戻ることで多くの時間を節約できるという印象があります。

とはいえ、アーキテクチャの決定が非常に制限されているレールのようなフレームワークがある場合、これらの問題は基本的に存在しません。

もう1つの問題は、テストを盲目的に信頼する場合です。真実は-他のコードと同様に-テストにもバグがある可能性があります。そのため、テストに対しても実装に対しても重要です。

TDDの大ファンとして、私はこれらの欠点を時々見ます

• コードカバレッジがほぼ100％であるために、あまりにも多くのテストを記述する誘惑。私の意見では、テストを書く必要はありません
  • 単純なプロパティゲッター/セッター用
  • 例外がスローされるたびに
  • 異なるレイヤーを通して同じ機能をチェックします。（例：すべてのパラメーターの入力検証を確認する単体テストがある場合、統合テストを通じてこれらのすべてのテストを繰り返す必要はありません）

• 同様のテストのテストコードのメンテナンスコストは、わずかに異なります（コードの複製（コピー/貼り付け/継承）によって作成されます）。既にお持ちの場合は、同様のものを簡単に作成できます。ただし、テストコードをリファクタリングしない場合、ヘルパーメソッドへのコードの重複を排除することにより、ビジネスコードの実装の詳細が変更された場合、テストを修正するのに時間が必要になる場合があります。

• あなたが下にある場合は、時間圧力あなたがしたくなるかもしれません壊れたテストを排除する（またはそれらをコメントアウト）の代わりに固定するそれらを。このようにして、テストへの投資を失う

TDDが価値のあるゲーム開発者として、私はまだ複数のシナリオに出くわしていません。そして、そのインスタンスは、本質的に純粋に数学的なコードであり、膨大な数のエッジケースを同時にテストするための堅実なアプローチが必要でした。

いつか何かが私の心を変えるかもしれませんが、XPのプラクティスの中で、容赦なくリファクタリングするという考えと、独自の形式に進化するコードははるかに重要であり、私にとって最大の生産性につながります。James Newkirkの論文からの引用：

シンプルさ-「動作する可能性のある最も単純なものは何ですか？」
メッセージは非常に明確です。今日の要件を考慮して、ソフトウェアを設計および作成します。未来を予測しようとしないで、未来を展開させてください。多くの場合、これは非常に予測不可能な方法で行われ、予測は費用がかかりすぎるために費用がかかる場合があります。」

彼が言及する勇気とフィードバックループの強化の概念は、私の考えでは、生産性の鍵でもあります。

私のネガティブTDDの経験は、限られているかもしれませんが、どこから始めればよいかを知るだけです！例えば、私は何かのTDDをしようといずれかのテストの些細な事を禁止する開始する見当がつかない（私は新しいことができますFooオブジェクトを、私はに渡すことができますQuuxにBaz、など。何をテストしていないテスト）、または既存のプロジェクトに実装しようとすると、TDDで使用できるようにさまざまなクラスを書き換える必要があることがわかります。最終的な結果は、この概念をすぐに完全に放棄することです。

ユニットテスト（TDDまたはその他）が何であり、なぜそれが良いことなのかを知っているのは、会社全体で私だけであることが多いので、おそらく助けにはなりません。

TDD熱狂者。

私にとっては、彼らは私の行方が取り返しのつかないほど壊れており、救いへの唯一の道がイエス、ケント・バック、またはユニット・テストであることを証明しようとする、私の宗教的ルーニーの一列に過ぎません。

IMO、彼らの最大の嘘は、TDDがより良いアルゴリズム設計の救済にあなたを導くということです。TDDで書かれた有名なSodukuソルバーを参照してください：ここでは、ここでは、ここでは、こことここ

TDDを使用せず、旧式のエンジニアリングを使用して行われたPeter Norvig数独ソルバーを比較してください。http：//norvig.com/sudoku.html

これらの「熱狂的な」記事のTDDを使用すると、ソフトウェアにエラーがないという誤った安全感が得られます。

TDDにはいくつかの利点があります。

• あなたは、に焦点を当てる方法を代わりにこの問題を解決するに焦点を当てたの（あなたが最初のテストを書いて）最初に期待するあなたのコードと何を呼び出してから、あなたは、アプリケーションからの呼び出しに接着します。モジュール性により、モックとラップが簡単になります。
• テストは、リファクタリングの前後でプログラムが同じように動作することを確認します。これは、プログラムにエラーがないことを意味するのではなく、同じように機能し続けることを意味します。

TDDは長期投資に関するものです。アプリケーションのメンテナンスモードに到達すると努力は報われますが、アプリケーションがそのポイントに到達する予定がない場合、投資を回収することはできません。

私は飛行機のチェックリストに類似した赤ん坊のステップでTDD赤緑サイクルを検討します。離陸前に飛行機内のすべてのものをチェックするのは面倒で面倒ですが、特に簡単な場合（TDDベビーステップ）は安全性が向上することがわかっています。すべてが機能することを確認することに加えて、基本的に飛行機をリセットします。つまり、飛行機は離陸する前に再起動されます。

TDDに対する私の否定的な経験は、多くの新しくて誇張されたもので感じるものです。実際、コードの妥当性を保証するTDDを楽しんでいます。さらに重要なことは、新しいコードを追加したり、何らかのリファクタリングを行った後、テストの失敗を認識できることです。

TDDについて私を悩ませているのは、それについて多くのルールやガイドラインがあるという事実です。まだかなり新しいので、私たちのほとんどはTDDの初心者になります。したがって、私たちの一部にとってうまくいくものは、他の人にとってはうまくいかないかもしれません。私が言いたいのは、TDDを実行するための本当の「間違ったまたは正しい」方法はないということです。私のために働く方法があります。

だから、テストを書く限り-実稼働コードの前後は本当に重要ではない-テスト駆動が本当に意味があるかどうかは、まだ証明されていないため、今述べられているすべてのガイドラインに従う必要があるかどうかわからない毎日の仕事に理想的なソリューション。テストを書くのにもっと良い方法を見つけたら、ブログに投稿するか、ここで議論するか、それについての記事を書くべきです。だから、10年かそこらで、TDDのどのルールが特定の状況で良いかそうでないかを判断できる十分な経験を共有したかもしれません。

不器用だったので、次の日に破棄したコードを複数回書いたことがあります。TDDで再起動しましたが、解決策は改善されました。ですから、私はTDDのネガティブな経験のラインにあまり入っていません。しかし、そうは言っても、私は時間をかけて問題について考え、TDD以外の分野でより良い解決策を考え出しました。

緊急システムに関しては、TDDのパフォーマンスが低いことがわかりました。私はビデオゲームの開発者で、最近TDDを使用して、複数の単純な動作を使用してエンティティのリアルな動きを作成するシステムを作成しました。

たとえば、異なるタイプの危険なエリアからあなたを遠ざける責任がある行動と、異なるタイプの興味深いエリアにあなたを移動させる責任がある行動があります。各動作の出力を統合すると、最終的な動きが作成されます。

システムの内臓は簡単に実装され、TDDは各サブシステムが何を担当するかを指定するのに役立ちました。

しかし、振る舞いがどのように相互作用するか、さらに重要なこととして、それらが時間とともにどのように相互作用するかを指定することになると、問題に遭遇しました。多くの場合、正しい答えはありませんでした。最初のテストは合格しましたが、QAはシステムが機能しないエッジケースを見つけ続けることができました。正しい解決策を見つけるには、いくつかの異なる動作を徹底的に繰り返す必要があり、ゲーム内で動作することを確認する前に新しい動作を反映するために毎回テストを更新した場合、何度もテストを破棄することになりました。そこで、それらのテストを削除しました。

私はおそらくQAが発見されたエッジケースをキャプチャし、より強いテストを持っていたはずですが、あなたは多くの物理学とゲームプレイシステムの上に座って、このようなシステムを持って、ときとあなたが時間をかけて行動を扱っている、それは少しになり何が起こっているかを正確に指定するのは悪夢です。

私はほぼ間違いなく自分のアプローチで間違いを犯しました。システムの根性について言ったように、TDDは見事に機能し、いくつかの最適化リファクタリングもサポートしました。