個人的には、「コードの前にテストを書く」ことを強調するJUnitエッセイを1つまたは2つ読むだけで、始められるのに十分であることがわかりました。
このテクノロジーを学ぶ上で最も重要な部分テストベースのコードをたくさん書くこと。コードを書くことについて考える最も基本的な方法のいくつかを変更する必要があるためです。次のようなもの：
- コードの前にテストを記述すると、コードを呼び出して結果を取得する方法を前もって考えることができます。つまり、使用方法に基づいてAPIfirstを設計します。これにより、APIが向上することがよくあります。
- 全体ではなくコードの一部をテストできるようにするには、よりモジュール化したものを考える必要があるため、コーディングスタイルが変わります。
- また、テストに合格したので、自信を持って主要なチャンクを引き出して、同じように動作する代わりに新しいチャンクを挿入できるようになります。オリジナルは寛大すぎるので、私は最近、日付解析ライブラリを使用してそれを行いました。
小さく始めるのに最適な場所は、ユーティリティルーチンです。次に必要なときは、最初にテストで設計するだけで、公式のすべてのユースケース（null値が渡されたときに何が起こるかなど）をカバーする多くのテストを記述し、すべてのユースケースが実装されると、使用できるはずです。コード内で直接、そして期待通りに機能することを確信してください。
また、さまざまな状況でコードがどのように動作するかを正確に示す非常に簡潔なコードがたくさんあるので、優れたテストがドキュメントとして追加の作業を実行できることも私の経験です。これは、正しいことが簡単に証明できます（緑色のバー）。注意深いコメントを付ければ、それ以上のものは得られません。
Java jUnitバージョン4は本当に素晴らしいです。
すでに言及した本の一部は別として、私は テストによって導かれる成長するオブジェクト指向ソフトウェア を推奨できます。私はまだそれを読み終えていませんが、単純なコード例だけでなく、まるで生き生きとしたTDDプロジェクトのストーリーも含めて、読む価値はあります。
私の意見では、TDDは、テストを記述するよりも、コードをテスト可能にすることです
もちろん、コーディングの前にテストを記述できますが、テストが記述される理由は、コードを記述できるようにするためです。テストが難しいコードの記述を妨げるものではありません。
これを見て、私の意味をよく理解してください：My Unified Theory of Bugs
この概念に興味があり、さらに詳しく知りたい場合は、コメントしてください。Googleからのトピックに関する記録されたプレゼンテーションの方向を示します。
UPDATE：
MiškoHevery プレゼン（By GoogleTechTalks ） Google in NYC およびGoogleのスポンサー Engineering Productivity グループ
私は2冊の本を読みました：
テスト駆動開発：例 ケントベックと
nit Test Frameworks by Paul Hamil
Beckの本はよく評価されていますが、「ユニットテストフレームワーク」を読むまではユニットテストを開始していませんでした。 TDDをいくつか行いますが、（可能な場合は）維持しなければならない古いコードにテストも追加します。
編集：また、一度ハンドルを取得したら、すぐに現在のプロジェクトで使用することをお勧めします。私にとってそれは本当の学習が起こったときであり、「ユニットテストフレームワーク」の本はこの目的のためのより良い参照本であると思います。 （私はC＃でnunitを使用していました）。
主にTDDについてではありませんが（それはそれに触れており、テスト容易性のための設計もしています）、 The Art of Unit Testing =良いテストの書き方を教えてくれるので、私が勧める本です。
より具体的には、信頼できる、保守可能で読み取り可能なテストを作成する方法を教えています。これは本の中で最も重要なセクションだと思います。おそらく、ユニットテストと分離フレームワークに関する基本事項は別です。単体テストが問題になる場合や、開発者の仕事に摩擦が生じる場合、それらの成功またはメリットが制限されることは明らかです。テストを作成するために時間と労力を費やした場合、その投資から最大の利益を得ることができるはずです。