最近、TDDに関する多くの記事がハブで公開されており、読者の間でさまざまな反応を引き起こしています。 これらの記事を読んでいる若い開発者は、TDDがおそらく素晴らしいという潜在意識のどこかで、定義と用語のhの中をさまよいます。
この記事では、会話の内容を説明しようとします。 TDDの目的とその使用方法。
TDDとは何ですか？ -これは、機能を実装する前にテストを作成する開発者です。
ロイオシェロフのアドバイスでは、TDDの適用可能性の問題を2つに分割します。
- テストを書く理由
- 実装前にテストを書くのはなぜですか？
とにかくテストする
クライアントにプログラムを配信する前にテストしない単一の正気な開発者はいません。 はい、開発者がいます。どの製品でも、製品は少なくとも視覚的にテストされます。 航空機の製造でさえ、靱皮靴を編んででも、どこでも製品をチェックします。 これは私たちにも当てはまります。 まだテスト中なので、このプロセスを自動化してみませんか？ ボタンをクリックするだけでできるのに、小さな変更のたびにすべての機能を手動で確認するのはなぜですか？
誰もがそれを必要とするわけではありません
テストを作成しない開発者のプロジェクトでは、Chuck Norrisと呼びます。彼らは信じられないほどクールであり、心からうらやましいからです。
チャックがテストを書かないのはなぜですか？
彼のコードは完璧です
Chuck Norrisコードにバグはありません。 彼は決して間違っていません。 Chuckのコードにバグを見つけた場合は、それについて話してみてください。これが実際にプロジェクトの必要な機能であることがすぐにわかります。
彼はプロジェクトに関するコードのドキュメントとコミュニケーションを必要としません
実際、文書化はコミュニケーションの1つの方法にすぎません。 コードを文書化することにより、プロジェクトに取り組んでいるチーム（現在および将来）と通信します。 テストは最高のドキュメントです。 開発者は紙のドキュメントをまったく読まず、これらの紙片やファイルはいつでもどこかに消えてしまいます。 コードについて書かれたコメントを理解することは常に可能とはほど遠い-著者が正確に何を意味したのか。 テストでは、コードがどのように機能するか、何を取得したいかをすぐに確認できます。
チャックはこのすべてを必要としません-彼は一人で働きます。
完璧な記憶
単独でどのプロジェクトに取り組むことができますか？ お客様が間違いなくあなたを見つけられないような暖かい国への飛行機のチケットを買った人だけに。 他のすべてのプロジェクトでは、少なくともあなたと一緒に仕事をします-あなたとあなたは将来的に。 そして、実装のテーマについて自分自身と通信する必要があります。 チャックはそれなしでうまくいきます-彼は彼のプロジェクトのすべてを覚えています。
問題なくリファクタリング
Chuckはコードがすぐに完璧なため、リファクタリングを一切行いません。 そのため、彼は何かを変更または最適化する必要があり、その過程で何かを壊さないようにしようとする状況はありません。
なぜテストを書かないのですか？
私はそれが何で、なぜなのかわかりません。
特にチャック・ノリスがテストを書かない理由を読んだ後の奇妙な言い訳。
時間がない
テストを使用すると、時間を節約できます。 現在、アプリケーションのデバッグと手動テストにどれくらいの時間を費やしていますか？ はい、テストの作成には時間がかかりますが、成果はあります。
テストすることは不可能です
ほとんどすべてをテストできますが、不可能なことは必要ありません。 モックフレームワークはこれに非常に役立ちます。 単体テストでは、プロジェクトのロジックをテストする必要があります。 データベース、外部サービスなどとの相互作用のテスト-これはすでに統合テストと機能テストに関する会話です。
これは私の仕事ではありません。
テスターがいます-テストさせてください。 テスターに残すバグが少なければ少ないほど、今後テスターと一緒に作業する必要が少なくなります。 より効率的に働く-雇用主はそれを高く評価しています。
気持ちいい
おめでとうございます、あなたはチャック・ノリスです。
テストは時間を節約します。 テストはエラーの繰り返しを防ぎます。 彼らの助けを借りて、コードははるかに効率的に文書化され、リファクタリング中にはるかに快適に感じることができます。
なぜ実装前にそれらを書くのですか？
ケントベックの「 Clean Code That Works 」は、この図とフレーズのTDDに関するものです。 私たちはコードを機能させ、クリーンにしたいのです。 以上です。 そして、実践が示すように、ステップRed-> Green-> Refactoringを使用すると、これは簡単に達成できます。
レッドステージでは、テストを作成し、関数の設計を評価して、すぐに修正します。 機能が実装されておらず、テストが失敗することを確認します。
グリーンステージでは、「Code That Works」という目標を達成し、実装が機能し始めます。
リファクタリングサイクルの最後の段階で、「コードのクリーン化」という目標を実現しますが、それはまだ「その動作」です...
TDDの主なアイデアはテストではなく、設計上の問題です。 テストを書くとき、何をしたいのか、そしてそれをどのように実装するのが最善かを自問します。 次に、途中で、 Keep It Simple StupidとYou Ai n't Gonna Need Itの原則に従って、コードデザインをテストします。
TDDを提供するのは自信です。 テストが書かれることを確認してください-機能の後にテストを書く場合、これをしない理由は千あります。 あなたのデザインに自信があります。 あなたが望んでいたすべてが実現されていると確信しています。
TDDは特効薬ではありません
ごめんなさい Frederick Brooksが彼の本で書いたように、銀の弾丸はまったくありません。 TDDも例外ではありません。 あなたはまだ間違っている可能性があります、あなたはテストで間違っている可能性があります。 単体テストはすべてに限定されるものではなく、統合テストや他のタイプのテストが必要になる場合があります。 TDDは、すべてのコードをカバーするには絶対に十分ではありません。 そして最も重要なこと-あなたはまだ考える必要があります:)そして、リラックスしないでください。
TDDの使用を開始するには？
... TDDの記事に記載されています-スノーボードのようなものです 。 要するに-あなたは注意する必要があります。 あなたは何をしているのか、そしてその理由を知る必要があります。 そして、最良の選択肢は、すでにこのアプローチを使用している人から学ぶことです。 これが不可能な場合-書籍、スクリーンキャスト、記事+本、記事を書いている人への手紙、何かが明確でない場合はスクリーンキャストを記録する。
TDDの使用をお楽しみください。 赤の後に緑のストライプが見えるのは本当に素晴らしいことです。 そして中毒性があります。 ただし、このすばらしいTDDの適用の限界に注意し、確認する必要があります。
足なしで放置されるリスク
準備されていない開始
問題の本質を理解せず、TDDに真っ向から突入すると、膨大な時間を無駄に費やす危険があります。 そして、すべてのリーダーシップがこれを容認するわけではありません。 最初に、テストの書き方を学ぶ必要があります。 次に、TDDに進みます。 シームレスに、突然の動きなし。 脳自体はある時点で切り替わります。
TDDのTDD
TDDはクールです。誰もがそれについて書いて、彼らはさらに話します。 それは根本的に間違っています。 準備ができていないスタートに非常に近い-それがどのように機能するかを理解してから始めましょう。
適用性を超えて
TDDを使用して、プロジェクトのロジックをテストする必要があります。 他のすべてについては、他のタイプのテストがあります。 そして、すべてのロジックがそのようなアプローチに適しているわけではありません-優れた例は、科学アプリケーションでユニットテストが機能しない理由の記事に記載されています
狂信
私たちは主に顧客のために働いています。 30分後に重要なプレゼンテーションがあり、緊急に新しい機能を実装する必要がある場合、テストの作成を開始し、実装を作成する時間がないと理解できません。 ビジネス上の目的でTDDを犠牲にする必要がある場合があることを理解する必要があります。
はじめに読むべきこと
テスト駆動開発：例による
最初の本はKent Beckの本であるべきです-このアプローチの著者からのTDDのすべての基本が含まれています。 必要な読書。
単体テストの技術：.Netの例を使用して
テストを書く-あなたが最初のスキルを習得するのに役立つ本。 TDDについては、いくつかの単語があります。 C＃の例ですが、それは重要ではありません。誰にとっても便利です。 ここで本の良いレビューを読むことができます 。
リファクタリング：既存のコードの設計の改善
コードをクリーンに保つのに役立つ古典的なMartin Fowleraoリファクタリングブック。
パターンへのリファクタリング
リファクタリングに関する別の本。 その中で、Joshua Kirievskyはリファクタリングとデザインパターンの関係を示しています。 ファウラーのすぐ後に読むことをお勧めします。
レガシーコードを効果的に使用する
マイケルフェザーズによる、レガシーコードを適切な方法で操作する方法を詳述した本。 著者が「継承コード」の概念をどのように定義するかは興味深いです。テストによってカバーされないのはコードです:)このようなコードを扱う人にとって非常に便利です。
テストを作成してTDDを使用することを望んでいますが、本当に必要な場合にのみ使用してください。 足に注意してください。
この記事は、.NET Developers Conferenceでの最近の講演に基づいています 。