TDDはスノーボードのようなものです

次の手紙を受け取りました。これを公に共有して回答したいと思います。



「私にとっての主な疑問が未解決のままであるという事実のため、私はこの方法論（TDD）を使用しません。 TDDを使用するとバグの数が減ることはわかっていますが、この方法論の作業に要する時間はどうですか？

TDDを使用してエンタープライズアプリケーションを開発するための時間はどのように変化するのかを知りたい-減少、増加、または変化しないままです。

TDDとBDDは私にとって非常に興味深いので、答えていただければ幸いです。」





私が注目したい最初で最も重要なことは、バグの数を減らすツールとしてTDDの誤った考えです。 これはTDDの「副作用」の1つですが、それを使用する主な動機ではありません。 TDDの主な論点は、システムの各コンポーネントのテストを作成することによる一貫した設計です 。



次の質問について：



「TDDを使用してエンタープライズアプリケーションを開発する時間はどのように変化するのかを知りたい-減少、増加、または不変のままです。」



最初に山に登り、スノーボードに乗る危険を冒すことに決めたとき、数分を切り抜け、 SSX Trickyよりもクールなトリックを実行する方法を夢見て、そこに登ります。 しかし、2、3回転倒すると、現実の重みのあるキックを感じ、輝きと魅力なしで少なくとも山から出ることを学ぶまでには少し時間がかかるように思えます。 慎重であれば、1日で基本と装備を教える資格のあるインストラクターと一緒に授業に時間を費やしてください。 インストラクターとのレッスンに基づいて、あなたは今後数ヶ月間スノーボーダーとして成長することができ、おそらくあなたが習得できる悪い習慣を拾わず、自分で学ぼうとします。



スノーボード（およびマスターすることにした他の新しいビジネス）の場合と同様に、最初は学習に時間を費やす必要があります。 TDDに飛び込むことを決めたほとんどの人は、この新しい世界で問題を引き起こす可能性のある知識に多くのギャップがあることを認識しています。 すべてが知識を備えている場合でも、いずれにせよ、初めて異常な方法でソフトウェアの問題を解決するために脳を訓練することに注意する必要があります。 実際、これはTDDに切り替える際の最大のハードルの1つです。小さなプログラミング手順を考え、すでに作成されているかのようにAPIを開発する新しいプログラミングスタイルを開発します。 TDDの練習を開始する良い方法は、状態ベースのテストを使用することです（ transl。から-テストに合格した後にオブジェクトの状態をチェックするアプローチ ）。 状態ベースのテストを理解したら、相互作用ベースのテストと組み合わせることができます（ transl。から-オブジェクトの相互作用、メソッドの動作、呼び出しのシーケンスなどをテストするアプローチ ）。



TDDの使用を開始すると、通常よりもゆっくりと作業していることに気付く場合があります。これは主に、「快適ゾーン」の外で作業し、不自然に感じるためです。 テストを書くことがワークフローの自然な部分になり、プロジェクトで作業するときにTDDを使用する必要がなくなったと感じたら、TDDが作業に統合されているため、TDDで「AHA！」の瞬間をつかむことができます。



プロジェクトに1つの機能を実装するように依頼されたほぼ同じレベルの開発者と2つのチーム（一方はアジャイル）の作業を目撃しました。 TDDを実践しているチームは、TDDを使用しなかったチームよりもタスクと要件の変更にはるかに適しています。 企業レベルでの小規模プロジェクトから巨大プロジェクトまで、さまざまなプロジェクトに対するTDDの影響を何度も観察しました。 TDDが本当に注目に値すると思わなければ、TDDの利点については語りません。 私にとって、このアプローチはプログラミングの問題を解決するという私の見方を完全に変えました。



開発者が獲得した他の多くのプログラミング機能および問題解決アプローチと同様に、TDDはプログラミングスタイルのもう1つの特徴的な機能です。 問題を解決するとき、最初にすべきことは、実装する要件を理解するために落下テストを書くことです。



一般的に、TDDパスを十分に長く追跡して、作業アプローチの不可欠な部分になるようにする必要があります。 そうしないと、TDDが開発者の兵器庫にもたらす利点について学習することなく、すぐに降伏する危険があります。



TDDの使用を真剣に検討しているが、まだ始めていない人にとっては、おそらくこれは丘を登るのに良い季節です！