TDD

TDD(Test-Driven Development)

テスト駆動開発（TDD）は非常に短い開発サイクルの繰り返しに依存するソフトウェア開発プロセスです。最初に、開発者は要求される新しい機能に対する自動化されたテストケースを作成し、そのテストをパスする最も簡単なコードを作成します。一旦テストに合格するコードを書き、状況に応じてリファクタリングする過程を経ます。つまり、テストがコード作成を主導する開発方式であるということです。

Add a test

テスト駆動開発（TDD）では、新しい機能を追加する前にテストを先に作成します。テストを作成するためには、開発者はその機能の要件や仕様を明確に理解している必要があります。これはユーザーケースやユーザーストーリーなどで理解することができ、開発者がコードを書く前に要件に集中できるよう支援します。これは非常に重要な部分であり、テスト駆動開発がもたらす利点と言えます。

Run all tests and see if new one fails

新しい機能を追加すると、正常に動作していた機能が正しく動作しなくなる可能性があります。 より危険な場合は、開発者がこれを見逃すことができない場合です。 これらの問題を防ぐために、テストコードを作成することが重要です。 新しい機能を追加する際にテストコードを作成することで、新しい機能が正しく動作すると同時に、既存の機能が正しく動作することもテストで確認できます。

Refactor code

‘良いコード’を書くことは本当に簡単ではありません。コードを書くときには、考慮すべき要素が1つや2つではありません。読みやすくするためにcoding conventionを合わせる必要があり、メソッド名、変数名、クラス名に一貫性を持たせるためにネーミング規則を適用する必要があります。また、将来の拡張性にも配慮する必要があります。同時にビジネスロジックについても考慮しなければならず、例外処理部分も見逃すことはできません。もちろんコード量が少ない場合は、いろいろなことに注意を払いながらコードを書くことができますが、デバッグの過程で発見されるバグによってコードが汚れることがよくあります。

そのため、コード量が膨大になるとリファクタリングを行うことがあります。このとき、テスト駆動開発を通じて開発を行ってきた場合、テストコードがその中心を担うことができます。肥大化した関数を複数の関数に分割する過程で、該当する機能が誤動作を引き起こす可能性がありますが、簡単なテストを実行することで安心してリファクタリングを続けることができます。結果的に、リファクタリングのスピードも速くなり、コードの品質も向上することになります。コードの品質の部分をもう少し詳しく見てみると、よりオブジェクト指向的で拡張性が高く、再設計の時間を短縮できるコード、デバッグ時間を短縮できるコードがTDDと共に生まれるのです。

どうせコードを書いた後には、正しく動作するかどうかを判断する時が来ます。もちろん途中で手動で確認することもあるでしょう。また、テストに関するドキュメントも作成する必要があります。その部分を自動的に行い、コード作成に役立つのがTDDなのです。TDDの賛美の言葉ばかりを繰り返してきましたが、TDDを初めて聞く人は、このような良いことをなぜしないのかと疑問に思うかもしれません。

疑問点

Q. コード生産性に問題があるのではないでしょうか？

コード量が倍増するわけではありませんが、確かにコード量は増加するでしょう。ビジネスロジック、各種コードデザインにも多くの時間がかかる上、テストコードまで作成するのは容易なことではないでしょう。コード品質よりも速い生産性が求められる段階でTDDは大きな障壁になる可能性があります。

Q. テストコードの作成は簡単ですか？

これもTDDという開発手法を適用する上で大きな障壁となることがあります。エントリーバリアが存在するということです。どの部分をテストすべきか、どのようにテストすべきか、多数のテストフレームワークの中から自社サービスに合ったものは何かなど、多くの部分について学習が必要であり、慣れるにも時間がかかるでしょう。一人が慣れたところで解決するわけではありません。開発はチーム単位で行われるため、チーム全員の同意が必要であり、チーム全員が慣れるまでテストコードが輝くことはありません。

Q. すべての状況に対してテストコードを作成できるのか？作成する必要があるのか？

世の中には様々なユーザーが存在し、想像もしなかった例外ケースが存在することもあります。もしもテストを必ずしも試さなければならない部分において、テストコードを作成するのに困難が生じた場合はどうでしょうか？このような状況で、実際のコードがより中心になるべきなのに、テストのためにコードの構造を変更しなければならないかどうか、という悩みが生じます。また、発生する可能性のある状況に対するテストコードを作成するために、過度に大きくなるケースも多々あります。実際の実装コードよりも巨大なコードを管理することも容易ではありません。

すべてのコードに対してテストコードを作成できるわけではなく、作成する必要もありません。また、テストコードを作成したからといってバグが発生しないわけではありません。元々TDDは100%カバレッジと100%整合性を主張していませんでした。