Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
今日はクリスマス・イブなので、サクサクっといきます。
みなさんも今日ぐらいは週40時間労働（あ、まだ解説してないや．．．）をきっちり守って、早めに帰ってくださいね(^_^)
システム開発でテストっていうと、「えー！？めんどくさい」とか「テストなんて役に立つの？」．．．そんなイメージないですか？
でも、あらためて「テストって何？」「テストってどうやってやるの？」と聞くと、その答えは人によって相当バラバラのようです。
そんなあいまいさがあるにも関わらず、なぜか「めんどくさい」というイメージだけは定着している．．．不思議ですよね〜。
このテストという単語、かなりのくわせものです。
明確な定義なしにこの単語を使うと．．．100人いたら、100通りの解釈が出る．．．そんな単語です。
「これテストしといてよ」なんて気軽にお願いした日にゃぁ．．．(-_-u
これまでテストは、プログラムやモジュールがある程度できあがった後にやるものだと思われ続けていました。また、テストのやり方も手動オペレーション＆目視確認が一般的でした。
XPでは、この習慣を180度ひっくり返してしまいました。
１つ目は「テストはプログラムやモジュールを作るよりも前に行う」、２つ目は「テストは自動化する」。
これらについて少し解説しましょう。
最初にテストを行う
「ないものをどうやってテストするんだ？」
XP流テストをご存知ないあなたは、そう思うかも知れません。
でも、「ないものをテストする方法」は存在します。
それは．．．
「何もないから失敗するということをテストする」ということです。
たとえば、足し算をする機能があったとします。
今までのテスト方法であれば、この機能を作った後に「1と2をインプットすると3がアウトプットされる」といったテストを行ってきました。
XP流テストでは、この順番をまず逆にします。
「1と2をインプットすると3がアウトプットされる」といったテストを何も機能がない状態でテストします。
すると、当然アウトプットは3にはならず、失敗となります。
これがXP流テストの第１ステップ、「必ず失敗することを確認する」です。
このとき何らかの間違いで3がアウトプットされていたら、そもそもテストのやり方に間違いがあることを従来のテスト方法では発見できませんでした。そこをわざと失敗させるのが、この第１ステップです。
第２ステップは、「最低限の実装をする」です。
すでにテストはあるので、テストを満たすための最低限の機能を実装します。
この場合だと、機械的に3をアウトプットすればいいので、「3をアウトプットする」機能を作ります。
すると、テストは成功します。
でも、このままでは「2と3をインプットすると5がアウトプットされる」といったテストは成功しそうにありません。
そこでまず、「2と3をインプットすると5がアウトプットされる」というテストを行います。これまた当然ですが、3がアウトプットされて、テストは失敗です。でも、この失敗を確認するのが重要です。
ここではじめて3をアウトプットするだけではダメだということになり、やはり最低限の実装を繰り返します。
「インプットを足した結果をアウトプットする」という機能に作り変えましょう。
そうすると、「2と3をインプットすると5がアウトプットされる」というテストが成功するようになります。
もちろん、「1と2をインプットすると3がアウトプットされる」というテストも成功のままです。
これが最初にテストを行うというコンセプトです。
この方法でプログラムやモジュールを作っていくと、テストが必ず用意されるようになり、しかもテストが通る最低限の実装をすればいいことになります。便利ですよね？
やってみるとわかりますが、これは開発側にとって非常に大きな自信となり、開発にかかる時間と人数を大幅に短縮することができます。一度このコンセプトで開発をすると、従来のやり方には絶対に戻りたくないと思う人が多いようです。
この例では、ひどく単純なサンプルを紹介しましたので、まだ実感が湧かないかも知れませんが、より実践に則した事例を実践シリーズで詳しく紹介しますので、楽しみにお待ち下さい。
なお、XPではこのコンセプトを「テストファースト」もしくは「テスト駆動開発（TDD:Test Driven Development）」と呼んでいます。
テストを自動化する
さきほどの「テストファースト」は、とても有効なテスト方法なんですが、それを何度も繰り返すとなると、従来と変わらずとてつもなく大変な作業となります。
しかもほんの少し機能を変えただけで全てのテストを手動でやり直すと考えたら．．．普通の人間の神経じゃぁそんなこと考えられないし、耐えられません。
そんなときこそ、私達になじみの深い、コンピュータの出番です。
コンピュータは、何度同じことを繰り返そうが、やり直そうが、不平や不満も言わないし、疲れてダウンすることもありません。
だから、XP流テストでは、テストはコンピュータにやらせます。手動＆目視確認でやっていたテストを全部コンピュータにやらせることで自動化するのです。
でも、どうやって？
答えはとても簡単です。
「テスト自体をプログラムにしちゃえばいい」、ただそれだけです。
たとえば、さっきの例で言えば、「1と2を機能にインプットしたら3がアウトプットされることをチェックする」「2と3を機能にインプットしたら5がアウトプットされることをチェックする」、そんなテスト用プログラムを作ればいいのです。多少なりともプログラミングに縁があれば、これはそれほど難しい話じゃないですよね？
そうやって自動化されたテストをシステムの開発と共に積み上げていけば、システム全体を全自動でチェックできるテスト用プログラムが用意されることになります。
つまり、システムは自動化されたテストのおかげでいつでも、何度でも、システム自身が壊れていないかをセルフチェックできるようになるのです。
更にこのセルフチェックテストは、開発環境以外でも使えるとしたら？
リリースをしたら動かないなんてことがなくなる訳です。これって理想的だと思いませんか？
次回は、テスティングと双璧をなすプログラマのためのプラクティス、「リファクタリング」を年明け1/14(金)にお届けします。
では、よいお年を！(^_^y
There is no comment.