|
|
/*========================================================*/ ＜＜＜あゆしゃのＣ言語プログラミング＞＞＞ /*========================================================*/ 第３８０回 XP３ テスト駆動開発 発行 ２００３年８月２７日（水曜日） 発行数 約３２００ {magclick} {magclick} /*========================================================*/ はじめに （ 決り文句 ） /*========================================================*/ ・このメールマガジンはまぐまぐさんから発行しています。 ・ジャンルは、マルチメディアのプログラム、Ｃ言語です。 ・このメールマガジンは、横６０文字で作成しています。 また、インデントはすべて半角スペース４つで構成しています。 ・ここで扱うプログラムは、C言語と半光年以内のものです。 ・登録解除は、まぐまぐさんのホームページでお願いします。 ・まぐまぐさんのバックナンバー（下欄参照）を活用して下さい。 ・ここは私の復習の場です。内容は約１ヶ月内外に私が勉強した 内容になっています。最新の技術があれば、へたれもあります。 ・わかりやすさを優先させる為、たまに嘘があるかもしれません。 /*========================================================*/ ご挨拶 /*========================================================*/ こんにちは。あゆしゃです。 先日、レンタルビデオにて新生ネバーエンディングストーリー の第１章をみました。 よくもまぁあそこまで、原作を愚弄できるものですねぇ。。 これもハリウッドでしたでしょうか？ しかしハリウッドの 最近の愚弄振りはすごいですよねぇ。 バットマンは愚弄しすぎて製作禁止になりましたしねぇ。 ザリングにいたってはホラー映画、ジャンルが違うじゃん。 日本版のリングは、９５％つまらないのですが、残りの５％が すごく好きです。 それはリングがホラーではなくミステリーだからです。 それをホラーにするなんて。いったい何を考えているのやら。 まぁ、私はミステリーやホラーは好きではないのでどうでもいい といえばどうでも。。。 {magclick} /*========================================================*/ 今回のお題 ＜＜ XP３ テスト駆動開発 ＞＞ /*========================================================*/ まずは１２回分の連載の内容についてまとめます。 １ XPって何？ ２ ペアプログラミング ３ テスト駆動開発 ４ 短期リリース ５ ユーザテスト ６ 全員同席 ７ 最適ペース ８ コード共同所有 ９ 常時結合 １０ リファクタリング １１ シンプル設計 １２ 計画ゲーム 私の好きな順番で並べました。 XPを知っている人はメタファという項目がないなぁというかも しれませんが、つまり私が嫌いということです。勘弁ください。 コーディング規約という項目もあるのですが、現状においても 当たり前であることなので、あえてはずしました。 そのほか、リリース計画やイテレーション計画もありませんが、 これらは総合的で高度な項目なので、はずしました。 （すいません、本当は１２という計画に入らなかった為です） さて、今回は３番ですね。 /*========================================================*/ ３ テスト駆動開発 /*========================================================*/ V字曲線というものを知っているでしょうか。 要求仕様書 要求テスト仕様書 ↓ ↑ 外部仕様書 外部テスト仕様書 ↓ ↑ 内部仕様書 内部テスト仕様書 ↓ ↑ 詳細仕様書 → 詳細テスト仕様書 というようなカーブのことです。 このように、仕様書とテスト仕様書はついになるべきものです。 （テスト仕様書の名称には、いろいろと方便があるでしょうから、 ここでは無理やり仕様書の名前と合わせました） そしてこの２つを同じ高さに並べて、開発を進める順番に線を 引くと、V字になります。 これがV字曲線です。 まぁそれはともかく、プログラムを行うときに、何を見て 作業を行いますか？ 仕様書でしょ、普通？ しかしXPでは、それが駄目だというのです。 /*========================================================*/ XPは、プロジェクト計画の数ある失敗例をもとにして作られて います。 切羽詰ったプロジェクトはまず、テストをなーなーにします。 まったくしなかったり。したと偽ったり。 テスト駆動開発は、テストという工程が軽視される現実を問題 として、テストが軽視できないルールとして作られました。 どうすれば軽視されないかというと、コーディングよりも先に テストを行う、というルールにしたのです。 /*========================================================*/ コーディングを行う前に、仕様書を見ます。 そしてその仕様書をもとに、コーディングを・・・ するのではなくて、テスト仕様書を作ります。 そしてコーディングは、テスト仕様書に書かれているテスト項目 をパスすることを目的として行います。 通常は仕様書どおりにコーディングすることを考えるでしょうが それに問題があるというのです。 バグも問題の１つですが、作ったら満足して実行確認をしなかっ たり、その実行確認が不十分だったりしがちです。 しなかったというのはともかくとして、実行確認が不十分という のは、仕様書を見ながら頭の中でテスト項目を作り、それを確認 するだけで済ませてしまう、という単体テストの方法によります。 よってXPでは、まずテスト仕様書を作りなさいと教えています。 /*========================================================*/ テスト駆動開発というのは、なんだか画数が多くて分かりづらい 名前ですね。 ちなみに「てすとくどうかいはつ」と読みます。念のため。 ようは、テストが常に行われている開発、ということです。 テストが軽視されていません、ということですね。 少し前は、テストファーストという名称でした。テストを先に、 という、まったく分かりやすい名称です。 テストファーストの何がいけなかったのか、アカデミックでは ないのが気に入らなかったのでしょうか、今はテスト駆動開発と 言われています。 作るよりもテストが先では、何だ、常に欠陥品であり続けると いうことなのか、とかいうイチャモンでもついたのでしょうか。 /*========================================================*/ 皆さん、ある機能を修正する場合にはどうしますか？ さすがにいきなり機能を修正する人はいませんよね、念のため。 まずは現状を把握し、次に修正箇所を確認し、修正内容を構築 し、そして修正を行い、最後に確認、しますよね。 テスト駆動開発は、まったくこのとおりなのです。だから、 上記の修正手順を踏んでいれば、もう、テスト駆動開発なんです。 /*========================================================*/ テスト駆動開発を行う場合、 ・機能内容を仕様書から把握 ・機能が実装されていないことを確認 ・機能に対するテスト仕様書を作成 ・テスト仕様書を満足するコーディングを行う ・テスト・デバッグを実行する という流れになりいます。 まだ機能を作っていないから機能が実装されていないことを 確認する必要はあるのでしょうか？ 大有りです。 それを怠ったために、私は何度失敗したことか。。。 それにやってみて、この機能が実装できる状態であるという 判断をやっておく必要もあります。 「ちょっとこのサーバのコード、コンパイルが通らないジャン！」 なんてことがあるかもしれません。十分ありえる話です。 なんどそういうソースをサーバに入れて失敗したことか。 １００行コーディングしてもコンパイルエラーを出さない妙な 自信があるので、コンパイルせずにアップするのですねぇ。 バカですねぇ。 は〜い、バカです。最近ONEPIECEにはまっているからかな！ /*========================================================*/ 冗談はともかく、機能を実装していない状態でテストをパスする こともありえます。 たとえば、えーと、おもいつかんなぁ。。。やばっ。。。 あるんですよ！ あ、思い出した、ほかでダミーコードが生きていて、見た目的に この機能が動いているっぽい状態にあるときです。 つまり追加した関数が呼ばれもせず、でもなんだか１発で動いた なぁ、ぼくは天才だなぁ、えっへん、なんて状態になると、将来 大変なことになるでしょう。 ＜納品後の怖いお話＞ 「ちょっと、この機能不十分だよ」 「ええ、ちゃんとテストはOKだったのに」 「ブレイクをはってみようか」 「あれ、ブレイクとまらんやん・・・えーなんで？」 「呼び出し元でとめてみて、あ、ダミー関数使っているよ」 「ぐは、まじ？ じゃ、ちょっと、呼んでみようか」 「うあ、ダミーよりひどいやん・・・」 「どうしうよう、報告する？」 「うーん、○○さん、電話で怒鳴り散らして、そんな雰囲気じゃ ないしなぁ、夕方ぐらいに」 （そして夕方） 「○○さん、ちょっと落ち着いたみたい」 「実はこうこうこうで・・・」 「昼過ぎにユーザさんに言われたよ」 なんて。ちなみに実話ではないことを望む。 /*========================================================*/ テスト駆動開発により、ソースと一緒にテスト仕様書と、その チェック結果が残ります。 ソースが動作するかどうかは、チェック結果によって証明し ます。 テスト仕様書がないと、口頭で「チェックしました」なんて 報告になりますが、 この報告を信じた人が何万人不幸になったことか。 発覚したころにはいないんだよね、外注さんって。 /*========================================================*/ ペアプログラミングよりも単純なプラクティスですよね。 /*========================================================*/ さいごに /*========================================================*/ 参考文献 よくわかる最新XPの基本と仕組み 長瀬嘉秀 監修 畑田成広 樋口博昭 著 秀和システム ISBN4-7980-9374-3 １９００円（税別）（ただし支給品） {magclick} /*========================================================*/ 次回予告 /*========================================================*/ 次回は８月２９日（金曜日）に、第３８１回を送ります。 お題は「XP４ 短期リリース」 まだヴィオのアトリエにいそがしいので、周一といたしたい ところですが、そうはいってはいられない事態になりました。 上司の命令により、あゆしゃは９月２０日にXPの社内テストを 受けなければなくなりました。 そこでこの１ヶ月の間、囲碁の話題を中断して、１ヶ月１２回に わたって、XPの特集を行います。 次回は短期リリースについてです。 お楽しみに！ /*========================================================*/ 最後の決り文句 /*========================================================*/ このメールマガジンは、まぐまぐさんから発行しています。 このメールマガジンを解除したい場合は、まぐまぐさんをご利用 ください。このメルマガのまぐまぐアイディーは最後にあります。 このメールマガジンには広告が挿入されます。 このメールマガジンの内容に文面の引用はありません。 めーらっくすの場合はめーらっくすの利用方に従ってください。 このメールマガジンの内容は、転用、流用、宣伝、リンク、 論理的に理由があるからミステリー。 なんて大歓迎です。 {magclick} /*========================================================*/ /*========================================================*/ 発行者 あゆしゃ まぐまぐアイディー 0000020674 まぐまぐバックナンバー http://jazz.tegami.com/backnumber/frame.cgi?id=0000020674 あゆしゃの世界 http://ayusya.hp.infoseek.co.jp/ 登録と解除 http://www.mag2.com/m/0000020674.htm ご意見・ご感想・ご質問メール mailto:ayusya@flamenco.plala.or.jp めーらっくす http://www.mailux.com/mm_dsp.php?mm_id=MM3E1AEE285AB4F |