これは、「プラグマティズムとドグマティズム」という古い対立についてです。 不満は主に私が独断的すぎるという事実にありました。 別の見方では、TDDの使用が正当化される場合もあれば、TDDのコストが高すぎる場合もあります。 ですから、あなたは実用主義者であり、賢明な選択をしなければなりません。
一見、この考えは完全に正当化されているように思えます。 結局のところ、プラグマティズムは良いですね。 TDDを適用しても期限に間に合わず、適用しなければ期限に間に合い、TDDを適用しないことを事前に知っているとしましょう。
そうだね。 質問はありません。 そして、実際、そのような道が正しいこともあります。 この投稿の目的は、私の意見では、TDDの使用が高すぎる場合を明確にすることです。
しかし、始める前に、私は要点を述べたいと思います。 TDDは、会計士向けの複式簿記や外科医向けのツール滅菌手順と同様に、プログラマー向けの分野です。 会計士が複式記入法を使用しない場合はありますか？ 外科医が器具を滅菌しない場合はありますか？
どちらの場合も、答えはイエスです。 私は、会計士が個人小切手帳の残高を調整するとき、またはレストランで合計請求額を調整するときに、複式記入法を使用することさえ疑います。 私は最初の声明について間違っている可能性があり、最終的に、私自身は小切手帳のバランスをとりながら、長年にわたって二重記録法を使用していました。 しかし、私は次第に、費やした努力が潜在的なリスクをカバーしていないことに気付きました。 最後の例については、レストランのアカウントをチェックするために、ダブルエントリー方式は過剰であることに誰もが同意すると思います。
さて、外科医と滅菌手順のために：数年前、私は足から脂肪腫を取り除いた。 私の妻はこの手順を見ました。 手術は医師のオフィスで局所麻酔下で行われました。 私の妻が手術の準備のためになぜ滅菌手順を行わなかったのかを妻が医者に尋ねたと聞きました。 彼は、このような簡単な操作には「クリーニング手順」で十分だと答えました。 妻と私はこの答えに満足し、医師が手術を行いました。
数日後、切開部は炎症を起こし、傷つき始めました。 感染が縫合糸の1つに入り、医師は切開を作り直し、そこですべてをきれいにしなければなりませんでした。 「クリーニング手順」が原因であるかどうかはわかりませんが、それ以来、私を治療している医師は「クリーニング手順」ではなく、滅菌手順を実行することを主張しています。
ただし、ステートメントはtrueのままです。 TDDが高価すぎて、より軽い規律を適用する必要がある場合があります。 私の話が、そのようなケースは非常にまれであり、プラグマティズムのミームが不適切と思われるからといって、あなたの専門分野の適用に対する障害にならないことをあなたに納得させてくれることを願っています。
実用主義。
TDDを使用しないのはいつですか？
- プロパティの取得および設定のテストは作成しません。 通常、このようなテストを書くことは愚かな慣行です。 これらの同じgetおよびsetは、他のメソッドのテストを通じて間接的にテストされます。 したがって、getおよびsetを直接テストすることは無意味です。
- メンバー変数のテストは書きません。 また、間接的にテストされます。
- 私は、単一行の関数や絶対に些細な関数のテストを書きません。 繰り返しますが、それらは間接的にテストされます。
- グラフィカルインターフェイスのテストは作成しません。 GUIテストには手間がかかります。 フォントサイズ、RGB値自体、XY座標、フィールドの幅を変更して、何かを配置する必要があります。 このようにTDDを使用するのは愚かで無駄です。
- ただし、重要な処理はGUIコードからテストに適したモジュールに移動されると確信しています。 重要なコードを未テストのままにしておくことはできません。 したがって、私のGUIコードは、データをプルして画面に表示する単なる接着剤とワイヤーにすぎません（MVVMまたはMVPに関する記事を参照）
- 一般に、試行錯誤によって「化学化」する必要があるコードのテストは作成しません。 しかし、私は私が確信しているコードからそのような「化学」を分離します
- 時々、私はもう少しコードが多いので、テストを書きます。
- また、場合によっては、既に「化学化」したコードを削除し、TDD方式で書き換えます。
- そのような状況であなたがすべきことは好みの問題です。
- 数か月前に、テストなしで100行のプログラムを作成しました（驚いたことに口を開きました！）
- プログラムは一度限りでした。 一度使用されてから捨てられました。 （私のビデオの1つで特殊効果を作成することを目的としていました）。
- プログラムは1画面長でした。 本質的には、純粋なGUIアプリケーションでした。 だから私はちょうど私が必要なすべてを1か所で台無しにしました。
- Clojureで作成し、シンプルなインタラクティブプログラミング環境がありました。 この単純な対話型環境から広大なプログラムを実行し、作成したコードの各行の実行結果を確認できます。 TDDではなく、EDD（Eye Driven Development-Visual Trackingによる開発）
- 通常、フレームワーク、データベース、Webサーバー、またはその他のサードパーティソフトウェアのテストは作成しません。 私は彼らのためにmokiを書き、彼らのコードではなく私のコードをテストします。
- もちろん、サードパーティのコードをテストすることもあります。 私はテストしています：
- 彼が壊れているという感じがあります
- モックを書くのが冗長になるほど、非常に高速で予測可能な結果が得られます。
これはすべて教義ではありません。
このリストは完全ではありません。 なぜテストを書かないことがあるのか、もう一度考えてみると思いますが、リストの本質は明確なはずです。 プラグマティズムは、TDDを実践すると効果を発揮しますが、教義ではありません。
しかし、私は教義を尊重します。 これには理由があります。 プラグマティズムが優先されることもありますが、 TDDの適用に最大限の努力を払わなければ、プロダクションコードの大部分を書きません。
翻訳者から：マーク・シーマンはボブおじさんのこの記事をすでに読んでおり、彼自身と反応しました 。 時間があるでしょう-私は翻訳しようとします。