[動画で解説]和田卓人の“テスト駆動開発”講座

第2回 「テスト駆動開発」とは何か?

この記事を読むのに必要な時間:およそ 2 分

ニコニコ動画:http://www.nicovideo.jp/watch/sm2195360

このWeb連載では,テスト駆動開発の啓蒙,つまりテスト駆動開発の紹介と説明を行っていきたいと考えています。そのためにはまず,「テスト駆動開発」という言葉の説明をしなければなりません。

テスト駆動開発は,よく略されて「TDD」と呼ばれます。これは「Test Driven Development」の略です。Drivenを「駆動」と訳すので,「テスト駆動開発」となるわけです。まずみなさんにテスト駆動開発とはどのようなものなのかを説明するところから,この連載を開始します。

テスト駆動開発の3ステップ

テスト駆動開発は,小さなステップを繰り返してプログラムの設計と開発を行っていくソフトウェア開発手法です。テスト駆動開発は次の3ステップから構成されています。

テスト駆動開発の3ステップ
  • ステップ1:これから書く機能に対するテストを1つ書き,テストが失敗することを確認する(レッド)
  • ステップ2:ステップ1のテストを通す最低限のコードを実装する(グリーン)
  • ステップ3:リファクタリングを行う(リファクタリング)

リファクタリングを行ったあとは,再度ステップ1に戻り,次に作成する機能のテストを書いてテストを失敗させ,コードを書き,またリファクタリングを行い……というサイクルを回していきます(リファクタリングとは何かについては後述します)。

では,各ステップをもう少し詳しく見ていきましょう。

ステップ1:これから書く機能に対するテストを1つ書き,テストが失敗することを確認する

テスト駆動開発では,まず1ステップ目として,これから書く機能のテストを1つ書きます。「テストを書く」と簡単に言っていますが,ここでの「テスト」とは,開発者が自分で書く,プログラムの形で書かれたテスト(テストコード)のことです。テストコードは通常JUnitなどのテスティングフレームワークによってテストの実行と結果の検証が自動化されていて,開発者は簡単なGUI操作またはコマンド入力でテストを実行できます(開発者が行うテストに関しては,次回でも触れる予定です)。

このときに,テストをたくさん書くのではなく,「1つ」書くところがポイントです。テスト駆動開発では,テストは一気にたくさん書くのではなく,1つのテストを書き,そのテストを成功させる過程でコードをより良くしていくことを主眼に置いています。一つのテストに対してテスト駆動開発の3つのステップを回し,終わったらもう一つテストを書き……という進め方をします。

ステップ1の最後に,テストが失敗することを確認します。これは重要です。ステップ1ではこれから作成する機能のテストを書くのですから,テストが成功するはずはありません。もしもステップ1で書いたテストがステップ2の前に成功してしまったら,テストの書き方がどこかおかしいということです。

テスティングフレームワークを使ってテストを行ったときには,テストが失敗するとGUIのテスト進捗表示部分が赤くなります。これをよく「レッドバー」と呼びます。ステップ1を象徴する色は,レッドです。

テストが予想どおり失敗すること(レッド)を確認したら,ステップ2に進みます。

Eclipseのレッドバー

Eclipseのレッドバー

ステップ2:ステップ1のテストを通す最低限のコードを実装する

ステップ2では,ステップ1で書いたテストを通す最低限の実装を書きます。機能が動作するところまで持っていくのがこのステップ2です。

ここで注目すべき点は,テストを通すための最もシンプルな手段を採るということです。最低限の実装とは,テストを通すために最短ルートを通ってよいということで,ステップ2の時点でコードの再利用性や設計の美醜などを考える必要はありません。あれこれ考えると私たちは手が止まってしまいます。ステップ2ではまず,テストを通すことだけを考えます。

テスティングフレームワークでは,テストが成功するとGUIのテスト進捗表示部分が緑色になります。これをよく「グリーンバー」と呼びます。ステップ2を象徴する色は,グリーンです。

Eclipseのグリーンバー

Eclipseのグリーンバー

ステップ3:リファクタリングを行う

ステップ2では,テストを通すために最もシンプルなコードを書くことを選択しました。すると,ステップ2で最低限の実装を書いた時点では,コードに無駄があったり愚直過ぎるコードだったりと,いくつか直したい点があると思います。たとえばコードの重複です。コードの重複とはその名のとおり,ソースコードのコピーなどを行った結果,部分的にダブり(重複)が発生してしまった状態をいいます。

自動化されたテストがステップ1で書かれ,ステップ2でテストが通る状態になっています。テスト駆動開発では,テストが通る状態を保つ限りは,コードの中身を変更してもよいという考え方をします。

ステップ3では,テストが通るままで,つまり,外部から見た振る舞いを変えないままで,コード内部の設計をより良くしていきます。これをリファクタリングといいます。

以上のの3ステップ(レッド-グリーン-リファクタリング)を1つの単位として,これを繰り返していくのがテスト駆動開発という手法です。このように,テストが開発を駆動していくからテスト駆動開発なのです。

今回のまとめ

今回,いくつか重要な点が出てきました。

  • 開発者がテストを書く
  • 実装よりも前にテストを書く
  • テストは全部一気に書くのではなく,少しずつ書く
  • 最短コースでテストが動作するところまで持っていく
  • テストが通るままでコードをきれいにする(リファクタリング)

次回は「テスト」という言葉について

今回はテスト駆動開発の大まかな概要を説明させていただきましたが,読者のみなさんは「テスト,テストって言うけど,テスト駆動開発のテストとはどのようなテストなんだろう?」という疑問や,今回説明している「テスト」というものに何か違和感を持たれている人もいらっしゃるのではないでしょうか。

そのような疑問を抱くのはごく自然なことです。読者の方々が疑問や誤解を抱くことなくテスト駆動開発を理解していただくために,次回はテスト駆動開発における「テスト」とは何なのかという話をさせていただきたいと思います。

著者プロフィール

和田卓人(わだたくと)

タワーズ・クエスト株式会社 プログラマ 兼 取締役社長。
2003年頃XPやテスト駆動開発に目覚める。後年「チームかくたに」のコーチとしてXPやTDDをチームで行った経験をもとに,『WEB+DB PRESS Vol.35』と『WEB+DB PRESS Vol.37』でTDDやリファクタリングについての巻頭特集を執筆。現在はSeasar.orgのコミッタとしての活動もしつつ,社長として会社を回している。

URLhttp://d.hatena.ne.jp/t-wada

コメント

コメントの記入