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
関連リンク
こんにちわ。ばたっちです。
原油の価格が上昇してる中、時速370kmも出るスーパー電気自動車 というのができてるそうです。
なんでも、ホイル(車輪)の中にモータが入っていて、直接タイヤ を回すという仕掛けだそうです。 写真を見るとタイヤが８つあります(^^;
何が優れているかというと、エネルギー消費をエンジンの１／４に しちゃったことです。
従来のエンジン式では、
エンジン→トランスミッション→プロペラシャフト→ドライブシャフト。。
その他云々を経由してタイヤに力が伝えられるので、無駄が多かっ たのですが、それに比べて、
モータ→タイヤ
にダイレクトに力を伝えることで、エネルギー損失(無駄)を格段に 減らすことで実現しているんですね♪
ソフトウェア開発も間に余計なもの(設計書、テスト仕様書。。(^^;) を省略して、損失を減らしたいですね。
そんなあなたには、XPの「テスト駆動開発」はいかがでしょう？
従来のドキュメント中心の情報伝達では、
設計−(設計書)→コーディング−(テスト仕様書)→テスト
のように、伝言ゲーム状態になり、情報の損失が大きくなります。
テスト駆動開発では、
自動テスト←→コーディング＋再設計
のように、やりたいこと(要求)を表現した自動テストが、ちゃんと 動くようにコーディングすることを、動くプログラムで確認しなが ら、進めることができます。損失はかなり軽減されます。
なんたって、動かしながら確認できるので、フィードバックが明確 です。(百聞は一見にしかず状態ですね(^^;)
※偶然ですが、コラムメンバーの最新記事がすべて「テスト」ネタ のようです。いかに、XPでは「テスト」が重視されているかという ことですね♪
今回は、ビジネス編、開発編の２本立てです♪(^^;
「ビジネス編」「開発編」
寿命の長いシステムでは、開発期間を半年とかに区切って、機能を どんどん追加していきます。 とまぁ、それだけ聞くと反復開発っぽくていいんですが(^^;
新しいバージョンのシステムがリリースされ、テストしていると、
「前に動いていた機能が、ちゃんと動かない！」
といった現象に遭遇します。
こういう、新しい機能を追加したことで、既存の処理(ソースコー ド)に問題が生じることを「デグレード」、略して「デグレ」といいます。
同じように、なんらかのバグが見つかり、それを修正してもらった ら、他の機能に影響があったということもありますね。
そんな現象が発生して、
「前のバージョンの機能が正常か確認しろ」
というと、
「レグレッション・テストを実施します」
といって、確認のためのテストをします。
通常は、前バージョンで実施したテストの項目をごそごそと引っ張 り出し、また、人を集めて以前に実施したテストを再度実施するん ですよねぇ。A^^;
場合によっては、新たに費用が発生することもあるでしょうね。(T_T;
従来の開発では、プログラムを修正したときに、修正箇所以外のど こに影響するかは、人による確認となります。
スーパープログラマ、あるいは天性の勘により、コードの問題箇所 を特定できるある種の天才(？)であれば、確実に影響箇所を洗い出 すことができるかもしれません。 (私にはできませんが。。 A^^;)
でも、人手作業には漏れが発生するもの。。
しかも、通常の開発では、
「動いたコードは触るな(変更するな)！」
というありがたい教訓があるため、コードは追加、追加の継ぎ接ぎ で影響箇所が絡み合ってしまい、なおさら、確認が難しくできてい ます。
。。そんなわけで、以前のバージョンの動作を保証する仕組みがな いため、大々的に再テストとなるわけです。
同じテストを何度も、時間(と、場合によってはお金も)をかけて実 施させるのって面倒じゃないですか？「MOTTAINAI」ですよね？(^^;
XPの「テスト駆動開発(TDD: Test Driven Development)」では、 プログラムによりテストを自動化した自動テストを作るので、レグ レッション・テストもすぐに確認できます。
通常、テスト駆動開発というと、「xUnit」というツールを使った 単体テストを指しますが、ここでは「継続的結合」「受け入れテスト」 といった、XPのテスト関係の手法をすべて含めて、テス ト駆動開発と言っています。
じゃあ、「テスト駆動開発」にするにはどうすればいいんだ？
それは、あなた(ユーザ)が期待するシステムの振る舞いの「具体的」 な例を、たくさんリストアップすること。 そして、それを実際に動かして確認するためのプログラムを用意し てもらうこと。
ただし、開発するソフトウェアはいろいろ、さまざま、それぞれな ので、簡単にはできないこともあります。
ライブラリのように APIの入力と、期待される出力の受け渡しで 済むような簡単なものもあれば、ネットワークシステムで、プロト コルの期待されるシーケンスを確認、あるいは Webなどの GUIの 確認。。のように、いろいろあります。
開発者に作ってもらわなくても、世の中にはすでに使える「ツール」 が存在しているかもしれません。
要は、あなたが期待する振る舞いを、なるべくあなたに分かる形 でテストできる仕組みを用意することが重要です。
テストの準備は慣れるまでは、多少時間がかかり、最初の立ち上が りが遅くなるかもしれません。
しかし、開発期間が長い、あるいは継続的に開発がある場合は、後 の作業での開発速度と効率は格段に向上します！
レグレッションにかかる時間が、元のテスト期間の半分とする T1 = 元のテスト実施期間 レグレッション１回の場合は「T1 ＋ T1 × 0.5 ＝ T1 × 1.5」 レグレッション２回の場合は「T1 ＋ T1 × 0.5 ＋ T1 × 0.5 ＝ T1 × 2」 ：
しかも、プログラムが長年使われてきたような、継ぎ接ぎで、スパ ゲティで、おんぼろコードな、もはや手をつけられないコードを 使わなければいけない場合でも、そのコードの質の悪さも、システ ムの振る舞いを保証するテストで封じ込めることが可能です。
テスト駆動開発は開発者のためだけでなく、あなたが期待するシス テムを実現するための、有効な手法であり、思想でもあります。 トライする価値はありますよ♪
ちなみに。。。今後のすべてのソフトウェア開発は「テスト駆動開発」 になります(。。と言い切ってみる)。 今から手をつけておくと、おいしい思いができるかもね。 (^_^)/~
