TDDとBDD/ATDD(1)　TDDはテスト手法ではない

はじめに

近年、AgileやScrumの普及に伴って、振る舞い駆動開発（Behavior Driven Development、以下BDD）や受け入れテスト駆動開発（Acceptance test–driven development、以下ATDD）にも注目が集まってきました。

そこで本連載では、BDDやATDDとは何か、どのように活用すれば良いのか考えていきたいと思います。

本連載の構成は以下の通りです。

本連載のメインであるBDDやATDDは、テスト駆動開発（Test-driven development、以下TDD）から派生した考えです。つまり「TDDとは何か」という理解がないとBDDやATDDを理解することが難しくなります。そこで今回は、TDDとは何か、TDDの目的は何かについて改めて考えてみましょう。

本連載を読み始める前に確認してほしいこと

対象読者について

本連載では、以下のような読者を対象として考えています。
・TDDのやり方を知っている、もしくはTDDを実践している
・BDDという単語は聞いたことある
・BDDのやり方は知らない

本記事でTDDのやり方については語りません

本記事では、具体的なTDDのやり方については割愛します。
理由としては、既に素晴らしい教材がネット上にあるからです。特に、TDD Bootcamp 2020 Onlineの和田卓人さんによる基調講演（動画）は是非ご覧ください。文字上でTDDを語るよりも多くの有益な考え方が示されています。
本記事では、TDDのやり方を知っている前提で、なぜTDDを行なうべきか、何を目的としているのかについて話します。

TDDはテスト手法ではなく開発手法である

「TDDとは開発手法もしくは設計手法の1つである」という理解が必要です。特に、TDDという名前から「テスト手法の1つである」という勘違いが非常に多いです。

TDDとは、「テストの方法」ではなく、あくまでも「手段としてテスト（テストコード）を用いた開発方法」です。

TDDは以下の3つを満たしながら作成していきます。
・Red…設計の指針や直近のゴールを明確にする（そのためにテストコードを記述する）
・Green…ゴールを達成する（つまりテストコードがPassする）コードを愚直に実装する
・Refactor…ゴールを達成させたまま（つまりテストコードがPassしたまま）、実装したコードを改善していく

ゴールを示す具体的な手段としてテストコードを用います。

BDDを考案したDan Northも自身の記事「We need to talk about testing（邦訳：テストについて話し合わなくてはならない）」の中で、以下のように述べています。

TDD、BDD、ATDD、および関連するメソッドは、その名前が示すように、テストに取って代わるものではありません。これらは主に設計および開発手法です。
（中略）
プログラマーは自分が単体テストを書いていると思っています。そうではありません。彼らは、設計の指針となる簡単な具体例をテストコード形式で書いているに過ぎません。