「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

最初に留意事項です。
「テスト駆動開発」や「TDD」と言われて「あぁ、アレのことね」と分かる方は最後まで読む必要ありません。
テスト駆動開発の英語表現が「Test Driven Development」です。



テスト駆動開発を「TDD」と表現することがあります。
この「TDD」が「Test Driven Development」の省略表現なのです。



※「Test Driven Development」を何となく日本語にすると「テストに突き動かされた開発」となります。[詳細]

以上が「テスト駆動開発（TDD）」の意味を知っている人向けの説明です。

「テスト駆動開発（TDD）って何？美味しいの？」な人は、このまま読み進めてください。
用語の中身について説明します。



それでは、いってみましょう。
まずは予備知識として

・プログラムの作り方
・ソースコード（コード）
・テストファースト
・リファクタリング

について説明します。
「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。

プログラムを作って動かすまでの一般的な流れは

１．人間語でプログラムの元ネタを書く
２．元ネタを人間語から機械語に翻訳する
３．翻訳された指示に従って、コンピュータさんが お仕事する

です。



コンピュータさんは人間語が分かりません。



人間様はコンピュータさんの言葉が分かりません。



プログラムは人間様が作るものです。
そこで最初は人間様が分かる言葉でプログラムを作ります。
コンピュータさんに対する「あれをやれ」「これをやれ」な命令を人間語で書くのです。



次に人間語で書いたプログラムの元ネタをコンピュータさんが分かる言葉に翻訳します。
実際に お仕事をするのは、コンピュータさんですからね。
コンピュータさんが分かる言葉に変換する必要があるのです。



コンピュータさんが分かる言葉に翻訳したので、コンピュータさんは命令の内容を理解できます。
指示に従って、お仕事をしてくれるでしょう。



かなり簡略化した説明ですけどね。
これがプログラムを作るときの流れです。

この話で登場した「人間語で書いたプログラムの元ネタ」を「ソースコード」と言います。



また「ソースコード」を省略して「コード」と表現したりもします。



テストファーストは「先にテスト用（動作確認用）のプログラムを用意して、テストがOKになるように実際のプログラムを作る やり方」です。
今回は「プログラム」と表現しましたが「処理」でも「コード」でも「関数」でも好きに読み替えてください。

例えば、そうですね。

ピヨ太君がケーキが出てくる箱を作ろうとしています。



テストファーストでは、先にテスト用のプログラムを作ります。
今回は「箱からケーキが出てくるかチェックする」プログラムを作ったとしましょう。



今の時点で「箱からケーキが出てくるかチェックする」プログラムを動かすとテスト結果はNGになります。
当然ですよね。
現時点ではケーキが出てくる箱は影も形もないわけですから。



ピヨ太君はケーキが出てくる箱を作りました……が、出てきたのはコーヒーでした。



「箱からケーキが出てくるかチェックする」プログラムを動かすとテスト結果はNGになります。
あるのは「ケーキが出てくる箱」ではなく「コーヒーが出てくる箱」だからです。



ピヨ太君は箱を改造してケーキが出てくるようにしました。



「箱からケーキが出てくるかチェックする」プログラムを動かすと今度はテスト結果がOKになります。
ケーキが出てくる箱があるからです。



このような

テストを先に用意して、そのテストが合格するように実際の物を作る やり方

がテストファーストです。

なお「テスト」とは言っていますが、システム開発とかでやる実際のテストとは少しニュアンスが違います。
「動作確認用」くらいのニュアンスで捉えてください。

リファクタリングは「プログラム自体の動きは変えないように気を付けつつ、ソースコードを書き換える作業」です。

１．無駄な処理を省いて処理の流れを分かりやすくする
２．ソースコードを見やすくする
３．仕事してる感を出す

のような目的でやります。



以上を踏まえて

まず動作確認用のプログラム（テストコード）を作り、次にテストコードによるテストに合格する最低限のコードを書き、テストに合格する状態を維持したままコードの中身をキレイに整理する（のを繰り返す）ことでプログラムを完成させる やり方

が「Test Driven Development」です。
専門用語を使って説明すると

テストファーストで最低限のコードを書き、リファクタリングして完成させる やり方

ですかね。
上でも書きましたが、一般的には「テスト駆動開発」や「TDD」と表現されます。
※本ページでも以降は「テスト駆動開発」と表現します。

例えば、そうですね。

ピヨ太君がケーキが出てくる箱を作ろうとしています。



テスト駆動開発では、先にテスト用のプログラムを作ります。
今回は「箱からケーキが出てくるかチェックする」プログラムを作ったとしましょう。



今の時点で「箱からケーキが出てくるかチェックする」プログラムを動かすとテスト結果はNGになります。
当然ですよね。
現時点ではケーキが出てくる箱は影も形もないわけですから。



この状態を専門用語で「レッド（red）」と言います。
テストコードはあるけど実際のコードがないからチェック結果がNGになる状態です。

逆に、この状態でチェック結果がOKになるのであれば、テストコードがおかしいです。
テストコードを直す必要があります。

あるいは、チェック結果が表示されるところまでいかない可能性もあります。
その場合もテストコードを直す必要があります。

レッドの状態を確認することで「とりあえずテストコードは ちゃんと動いてそうだね」を確認するのです。

さて、レッドの状態が確認できたら、次は いよいよ実際の物を作る作業です。
ただし、ここでは必要最低限の「動けば良いや～」な気分で作ります。
ピヨ太君はピヨ子さんに箱の中に入ってケーキを出してもらうことにしました。



この状態で「箱からケーキが出てくるかチェックする」プログラムを動かすと今度はテスト結果がOKになります。
ケーキが出てくる箱があるからです。
まぁ、実際には箱の中に入っているピヨ子さんが、あらかじめ持っていたケーキを投げているだけですけどね。



この状態を専門用語で「グリーン（green）」と言います。
中身が どんな状態かは分かりませんが、とりあえずテストに合格する実際のコードがある状態です。

さて、ここで ちょっと考えてみてください。
これで「ケーキが出てくる箱」は完成でしょうか？

今はピヨ子さんが中に入ってケーキを出している状態です。
これで完成と言えますかね？

きっと言えませんよね。
「ケーキが出てくる箱」と言われたら、なんか自動でケーキが出てきそうです。

そこでピヨ太君は「ケーキが出てくる」という状態を変えないように気を付けながら「ケーキが出てくる箱」を改造しました。
ピヨ子さんにケーキを出してもらうのではなく、ロボットを作って、そいつにケーキを出させることにしたのです。



これを専門用語で「リファクタリング」と言います。
動きを変えないように気を付けつつ、中身を変える作業です。

リファクタリングが終わったら「箱からケーキが出てくるかチェックする」プログラムを動かします。
もう一度テストするのです。



もしチェック結果がOKであれば、改造後の状態は「箱からケーキが出てくる」という条件を満たしています。
ピヨ太君の改造は、それで完璧かは分かりませんが、とりあえず成功していると言えます。



一方、チェック結果がNGであれば、改造後の状態は「箱からケーキが出てくる」という条件を満たしていません。
どんな改造をしたにせよ、やってはダメな改造をしたと判断できます。
すぐに改造前の状態に戻しましょう。



このような

１．まずはテストを用意し
２．テスト結果がOKになる最低限のコードを作り
３．テスト結果がOKな状態を維持しつつコードをキレイにして完成させる

やり方がテスト駆動開発です。

……というのが大雑把な説明です。

実際にテスト駆動開発をやってみようと思ったら、今回説明した内容だけでは足りません。
例えば「三角測量」とか、他にも なんか いろいろと知っておくべきことがあります。
そこら辺の あれやこれやは他のところで勉強してください。



あと、テストファーストとテスト駆動開発の違いを気にする人がいますが、個人的には気にしない方が幸せになれると思います。

人によってはテストファーストとテスト駆動開発を（ほぼ）同じものと捉えています。
人によってはテストファーストとテスト駆動開発を区別しています。
テストファーストとテスト駆動開発を区別している人同士でも区別の仕方が違ったりもしました。