だんのさん、こんにちは。
> > 現場の開発者は、GUIプ
> > ログラミングが主で、TDDを勧めても、なかなか飛びついてくれません。
私はこちらではじめて知りました。＞TDD
てっきり「トーキョー・ディズニー・・・」での一件か何かと思ってた
くらいで．．．。（お恥ずかしい）
> ちょっと工夫できるかなと思ったのが、
> ・GUIプログラム等でも、プログラムがミスっているのは、内部処理部分が
> 多い（と思う）ので、GUIのイベント処理部分と、内部処理部分をできる
> だけ切り離して、内部処理部分はテストする。
> ・状態遷移等がフレームワーク化できる場合は、デザインパターンを駆使
> してアプリケーション依存部分と切り離して、テストする。
> ぐらいでしょうか。
今回、私が携わっているプロジェクトでは、これら（特に"OO"に
関するモノゴトすべて）が”禁止事項にさえなり得る”という問題点
です。
いわゆる”組込み系”では、いまだに
「（LMの）サイズが・・・」
「ヒープ領域が・・・」
「CPUに電力を使わせないように云々・・・」
とかいった世界が在り．．．大変です、これは。
# しかも'Java'で、ですよっ！
実際、"Abstract Fctory"と"Chain of Responsibility"で設計した結果、
できあがったモジュールが”制限にひっかかるシロモノ”だった
のです。
# で、今まさに”りふぁくたりんぐ”です (TT) ← バカ
> 外部入力依存の部分を以下に減らすように設計するか、すなわち、どれだけ
> テストありきの設計にできるかが、これからの設計方針かなという気がしました。
”人的操作を入れなければならないテスト”
がある場合、表題の"TDD"はどう云ったことになるのでしょうか？
・・・って、まずは
--------------------------------------------------
「eXtreme Programming」
ISBN4-7981-0218-0
カ）翔泳社 \2,400-
--------------------------------------------------
を読んでみますねっ。
# だいたい"TDD"の意味を解ってませんし
> 特にTDOだと、テストありきなのだから、どうやってテストするのかを先に
> 考えないといけませんね。
"TDO"って、『テスト駆動指向』なのですか？
# 「Test Driven Oriented」の略？
実は、私は「（正確に）動けばええやんっ」と考える人間で、
つまり「どうやってテストするのか」の視点ではなく、「テスト項目は
何なのか」の視点なのです。
・・・えー、うまく伝えられれば良いのですが、早い話が
「例外は考慮しない」
「例外を考慮して欲しいなら、お金を出せ」
「お金を出すのがいやならマニュアル通りに操作しろ」
「そのかわり”比較的短期間”で且つ、”お安い料金”で
物を出そうじゃないか」
と云うわけです。
．．．いや、そういったスタイルが私の理想なだけなんですけど、ね。
仕事柄、話し相手が役席な方々やCEOが多いので”タカビー”
なのかもしれません。 :-<
# 考えが違うのに’しゃしゃり出る’なよって？ A^^;)
> 昔は、スタブだのドライバだのと、単体テスト用モジュールをそれぞれ作って
> いた時代があったのですから、テストするためには何が必要か、という前提で
> 話を進めないとだめな時代になってきた気がします。
そうですね。
”ユーザーのユーザーたる意識”とか。 :p
根本って、『元に帰属する』でしょ？当たり前だけど。
だったら
「使う側が賢くならんかい！」
というのが私の理論です。
違う話でわかりやすい例としては、
（たとえば悪徳業者に）
「だまされたーっ！（怒）」
「そう云った’手口’を知らない君が悪いんじゃないの？」
ということです。
・・・口が悪いですね、申し訳ない。
以上で消えます．．．。（う〜む、最悪じゃ）
２００２年９月１３日
ジャービル企画 三木