0-9:

//主にJSのTDDを想定してますが、JSに限らないと思うのでTDDとしてます。

TDDでコード書くのは色々はかどっていいけど、TDDしたことない人がいきなりTDDから入ると挫折する可能性が高いのでおすすめできない。

TDDでコードを書くには「テストフレームワークに関する知識」、「テスト手法に関する知識」、「テスト対象に関する知識」が必要なので、以下の順番で進めていくといいと思う。

1. サンプルコードをテスト形式で書く

最初はライブラリやアプリ自体の主要な機能を説明したサンプルコードをテスト形式で書こう。

サンプルコードの目的は主要な機能の説明なので、テストは簡単なほどいい。

まずはテストフレームワークに慣れるのが目的なので、こったテストを書く必要はないし、よく分からなければ「実際こうは動かないけど」と断った上でテストっぽくコードを書いてもいい。

とにかくまずは普通にコードを書いて、その中の主要なものだけでいいのでテストを書いてみよう。

2. すでに書かれたコードに対してUnitTestを書く

サンプルコードをテスト形式で書けるようになれば、ある程度「テストフレームワークに関する知識」は得られると思うので、次はすでに書かれたコードに対してUnitTestを書こう。

ただし、アプリケーションの表示を行う部分は関連するライブラリが多くてテストが大変なので、最初はライブラリとして切り出した部分に対してのテストを書こう。

ただ、その場合でもできるだけ表示に関連する部分のコードは少なくして、ライブラリとして切り出せないか考えよう。

UnitTestの目的はコードをメンテする時に既存の部分にバグが追加されないか確認するためなので、できるだけいろんなパターンでテストできるようにしよう。

また、なにかバグが見つかった場合、一旦バグが再現するテストを書いてから元コードを修正しよう。

ここではいろんなコードをテストすることでテストパターンを学ぶのが目的なので、できるだけいろんな形式をテストしよう。

テストの量も増えるのでテスト自体の実行時間も考慮しよう。

3. これから書くコードをTDDで書く

UnitTestを書けるようになれば「テスト手法に関する知識」は得られると思うので、次はこれから書くコードをTDDで書こう。

TDDの目的はコードがテストしやすい形式になることなので、最終的にそのテストをUnitTestとして使うかどうかはあまり気にしなくていい。

コード自体は「テストコード叩き->実コード叩き->テストコード修正->実コード修正->UnitTest実装」な感じで書いていくのがいい。

「TDDがいい」と言われる理由は、TDDで書いたコードをベースにサンプルコードにもUnitTestにも流用しやすいこと。

注意点として、TDDはテストの手法ではなく、設計手法なのでテストの網羅性とかは考えない（UnitTestは網羅性を考える）

（このため、「TDDではなく、BDDと呼ぼう」と言われる）