unit-testing - TDD に「テスト感染」するにはどうすればよいですか?

Question

私は、「テスト感染」した人々について読み続けています。つまり、TDD を「取得」するだけでなく、TDD なしでは生きていけないということです。彼らはいわば「変身」したのだ。問題は、どうすればそのようになるかです。

Answer 1

あなたはすでにTDDについて読んだことがあります。もっと読むことはあなたを興奮させるつもりはありません。

代わりに、本物の個人的なサクセスストーリーが必要です。

方法は次のとおりです。コアモジュール、外部システムに依存しないコード、または他の多くのサブルーチンからいくつかのコードを取得します。ルーチンがどれほど複雑でも単純でも構いません。

次に、それに対する単体テストの作成を開始します。（お使いの言語にxUnitなどがあると思います。）テストには本当に不快感を覚えます。すべての境界ケースをテストし、max-intとmin-intをテストし、nullをテストし、文字列と数百万の要素を含むリストをテストします。韓国語と制御文字、右から左へのアラビア語、引用符、円記号、ピリオドなど、エスケープしないと壊れがちな文字列をテストします。

あなたが見つけるものは....バグです！最初は、これらのバグは重要ではないと思うかもしれません。まだこれらの問題に遭遇していない、コードがこれを実行することはおそらくない、などです。しかし、私の経験では、前進し続けると驚かれることでしょう。小さな問題の数で。最終的には、これらのバグのいずれも問題を引き起こさないとは信じがたいものになります。

それに加えて、何かが本当に、本当にうまく行われているという素晴らしい達成感を得ることができます。コードが完全ではなく、バグがないことはめったにないことを私たちは知っているので、私たちが本当に自信を持っているほど多くのテストを使い果たしたとき、それは素晴らしいことです。自信はいい感じです。

最後に、私は愛を引き起こす最後のイベントは数週間または数ヶ月後に起こると思います。バグを修正したり、機能を追加したり、コードをリファクタリングしたりしていると、単体テストが失敗する可能性があります。"は？" 新しい変更が壊れたテストに関連している理由がわからないと言うでしょう。それからあなたはそれを見つけ、悟りを見つけるでしょう。あなたは本当にあなたがコードを壊していることを知らなかったので、そしてテストはあなたを救った。

ハレルヤ！

Answer 2

「テスト感染」のポイントの一部は、TDD を十分に使用し、TDDなしでコーディングしたくないほど十分に成功したことです。最初にテストを作成し、次にコーディングとリファクタリングを行い、バグの数が減り、結果としてコードが改善されるというサイクルを経ると、Zxaos が言ったようにそれが第二の性質になるだけでなく、うまくいくことはありません。 Code First に戻ります。これはテスト感染されています。

Answer 3

まずは TDD について学び、ワークフローへの統合を開始してください。方法論を十分に使用すると、それらが第二の性質になり、そのフレームワーク内ですべての開発タスクを組み立て始めることがわかります。

また、選択した言語の J-Unit (または X-Unit) フレームワークの使用を開始します。

Answer 4

一言、練習！TDDを実行することにはいくらかのオーバーヘッドがあり、それを克服する方法は、練習して、プロセスを支援するツールを使用していることを確認することです。あなたはあなたの手の甲のような道具を学ぶ必要があります。学習しているプロセスに沿って進むためのツールを学習すると、クリックして、最初にテストを記述してコードをフラッシュすることに堪能になります。その後、「テスト感染」します。

しばらく前にこれに似た質問に答えました。あなたもそれをチェックしたいかもしれません。私はいくつかのツールに言及し、TDDの学習について説明します。これらのツールの中から、Resharperと優れたモックフレームワークの選択は、TDDを実行するために重要です。あなたが十分に使用しているテストフレームワークに沿ってこれらのツールを学ぶことを強調することはできません。