テストファーストによるソフトウェア開発の衝撃（後編）

テストファーストがソフトウェアキテクチャに及ぼす多大な影響について説明する本稿。後編では、「究極の仕様書」と言っても差し支えないであろう受け入れテストについて触れたいと思います。

[瀬谷啓介，ITmedia]

　前回、「テストファーストでコードを開発することは、コードの質を高めることにつながる」と述べました。後編となる今回はそれに引き続いて、「究極の仕様書」と言っても差し支えないであろう受け入れテストについて解説します。

受け入れテスト

　システムを構成する小さな要素の動作確認をするテストのことを「ユニットテスト」と呼びます。一方、システム全体の動作確認をするためのテストのことを「受け入れテスト」と呼びます。「受け入れテスト」の目的は、顧客の要求をきちんと満たしているかどうかをチェックすることにあり、従って、顧客が用意したスクリプト言語で記述されるのが普通です。どんな言語で記述されるにせよ、「受け入れテスト」はプログラムであり、実行可能なものです。

　「受け入れテストは究極の仕様書」といっても良いでしょう。「受け入れテスト」を書くのは顧客であり（自社の品質保証グループである場合もあるでしょう）、プログラマーはこのテスト内容を読むことで仕様の意味を真に理解できるからです。

　先ほどの試験対策アプリケーションの例で見たように、テストファーストでユニットテストを記述する行為は、テスト対象のソフトウェアコンポーネントのアーキテクチャに大きな影響を与えます。それと同様に、テストファーストで受け入れテストを書くという行為は、システム全体のアーキテクチャに大きな影響を及ぼします。システムをテスト可能にするためには、アーキテクチャの上位レベルでテストの対象となるものを分離しなければならないからです。

　「プロジェクトの早期に受け入れテストを自動化した場合と、しなかった場合では、最終的なアーキテクチャに大な違いが出てしまう」ことになるでしょう。というのは、受け入れテストを自動化しようとするからこそシステムの分離が促進されるのに、それを手動で行ってしまったのではせっかくのチャンスを逃してしまうからです。

受け入れテストの例

　ここでは例として試験対策アプリケーションの受け入れテストについて考えてみましょう。コードをまだ何も書いておらず、設計についてもまったく検討していない段階が、受け入れテストについて考える絶好のタイミングです。もうお分かりのことと思いますが、このタイミングこそ、テストファーストでテストを記述する絶好のタイミングなのです。

　受け入れテストは、できるだけ楽に変更できるようにしておきたいので、シンプルなテキストファイル形式で書くことにしましょう。例えばスクリプトを次のように記述したとします。

AddQuiz 1019 "car,本,車,果物,機関車" 2
Check QuizNo 1019 Ans 2

　ここでは、まず新規のクイズ「問題Car、選択肢1本2車3果物4機関車」を、クイズ番号1019、正解が2であるとして登録し、次にクイズ番号1019の答えが2であることをチェックしています。こういったスクリプトを書くことは誰にでも簡単にできることでしょう。

　この2行をよく見てください。最初の行は試験対策アプリケーションによって処理される部分ですが、2行目は受け入れテストのフレームワークによって処理されます。これは、受け入れテストのフレームワークがこのテキストファイルを分析し、試験対策アプリケーションによって処理される部分と、受け入れテストのフレームワークによって処理される部分に分離できなければならないことを意味します。

　実は、受け入れテストのフレームワークがこのように振る舞わなければならないこと自体が、試験対策アプリケーションにすでに影響を与えているのです。なぜなら、この振る舞いを実現するためには、「フレームワークからの指令」と「ユーザーからの直接の指令」の両方を試験対策アプリケーションが受け付けられるように設計されなければならないからです。

　このように、「テストファーストの教えに従って受け入れテストを書いたことで、複数のリクエスタからの指令を受け取ることのできる機能を早い段階でサポート」しなければならなくなります。この要請によって、アーキテクチャは各リクエスタと試験対策アプリケーションの概念をきちんと分離することになるわけです。

まとめ

　「テストファースト」でテストを書くという行為は、実は設計行為であるということ、また、そのスタイルでソフトウェアを開発することで、ソフトウェアの分離構造が必然的に促進されることを見てきました。「テストファースト」がソフトウェア開発にどのような好影響を及ぼすのか、まず「頭」で理解していただけたのではないかと思います。

　しかし、自転車の乗り方を「頭」で理解しても自転車に乗れないように、「テストファースト」の真価は実体験を通してしか学べません。この記事をきっかけに「テストファースト」でのソフトウェア開発を一度経験し、その衝撃を肌で感じるきっかけになれば幸いです。

コラム：Eclipseとテストファーストソフトウェア開発

　Javaのフリーのソフトウェア開発環境として、有名なツールEclipseがあります。これはJUnitが標準でインストールされており、右クリックして[Run]→[JUnit Test]を選択するだけでテストケースが実行されます（図A）。

図A　Eclipse上でJUnit Testを実行

　すべてのテストがパスすればグリーンバーが表示されます。1つでもテストが失敗すると、レッドバーが表示され敗北感を味わいます。

　不思議なもので、グリーンバーが表示されるととてもうれしい気分になり、いつの間にかゲーム感覚でグリーンバーを取得しようと必死になってしまいます。そういった状況に深くはまってしまう症状をテスト熱中症と呼ぶのですが、実際にテストにはまってしまう人の気持ちが分からないではありません。グリーンバーの威力は絶大です。受け入れテストについては、FIT（Framework for IntegratedTest）というフリーツールを利用できます。

本記事は、UNIX USER 2005年4月号特別企画「テストファーストによるソフトウェア開発の衝撃」を再構成したものです。