ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

独断と偏見の「単体テスト」の解釈:プログラムの仕様書の有無で変わる?

2005-04-27 11:57:19 | 開発ネタ
今日は、独断と偏見による、単体テストの解釈なんてーものを書いてみたいと思います。というのも意見募集!単体テストってなんですか?というのを見たので。。

 「単体テスト」というと、プログラム単体のテストのことをさします。
 ので、「システム開発取引の共通フレーム SLCP-JCF」でいう、

・ソフトウェアユニットとデータベースの作成
 (ソフトウエアユニット=プログラムの基本単位、まあ、プログアムです)
 の後に行われる、

・テスト手順とテストデータの作成、テストの実施

 に相当するとおもってます。
 (PDFでよければここにあります。そこの「エンジニアリングの視点」の「1.4 開発サイクル」の「1.4.8 ソフトウェアコード作成及びテスト」)

 で、たしか、上記の共通フレームでは、「プログラムの仕様書があって、その仕様書に対して、プログラムがあっているかどうかをテストする」という形になっていたと思います(記憶違いだったらすみません)。

 上記の場合、詳細設計でプログラムの書き方が書いてあるので、それをもと(基準)に、テストする
  =>結局、ホワイトボックステストの形になると思います。




 で、問題は、仮に、プログラムについての仕様書が無かった場合(プログラムを書くための資料やインターフェースは決まっているが、プログラムをこう書きなさいという仕様書はない場合)。

 この場合、共通フレームのように考えると、なにを基準にテストしていいかわからなくなります。そうすると、いったい、単体テストというのは、なにをやることなのか、ぼやけてくると思います。

・インターフェースに入出力するものだけあっていれば良い?
 →でも、これって、インターフェースの結合テスト(IT1って言ってるところもあるかも?)
  とどう違うの?

・ホワイトボックステストで、網羅しているかどうかを。。。
 →でも、それって、そもそも、仕様を勘違いしてたらおしまいだしなあ。。。
  (仕様書を書いてないんだから、だれも確認できないわけで。。。)

 つーことで、プログラムの仕様書が事前に出来ていない場合、なにをテストしたらいいのだか、はっきりしなくなってしまうとウィリアムのいたずらは思ってます。

 なので、下請けフリーのSEのウィリアムのいたずらは、「単体テスト、どんな風にやりますか?」とききます。実際、やってること、まちまちなんで。





 問題は、プログラムの仕様書、詳細設計書をつくるか?ということです。
 COBOLの時代は、あった記憶があります
 (たぶん、共通フレームもその時代のことの話でしょう)
 で、最近、Webで、たとえば、Actionの中をこう書いてくださいという仕様書は。。。


 ごそうぞうに、おまかせするぞ!

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ちなみに、StrutsのActionメソッドに、ロジックなしでSQL文を直接書いた人(会社)の話

2005-04-27 08:07:46 | 開発ネタ
 ちなみに、以前のブログで書いた


(4)Strutsでやるとすると、Actionメソッドに、SQL文を直接書いて、商品台帳テーブルを更新するプログラムを書くのよ(@_@)!


 このはなしを詳しく書くと、
 ある在庫のシステムを、こういう感じで作って、納品してきた会社があり、
 そのあと、仕様追加するということで、ウィリアムのいたずらが、お仕事もらいました。
 (はじめに作ったときには、ウィリアムのいたずらは、かかわっていない)。

-----

 で、その、はじめにシステムを納品した会社は、商品台帳テーブルに数量を持って、その数量を修正することで、在庫としていたわけよ。
 ウィリアムのいたずらは、そのプログラムの仕様追加分の作成を頼まれたんだけど、その会社、もう、わけわかんないこというのよ。

 ちなみに、仕様追加分は、「日次で在庫日報を出す」

 その会社はなんと!
   商品台帳テーブルに年月日項目を追加して、
   毎日、商品台帳をつくることを提案してきた!
 そうすれば、日次の在庫をとってくるのは、いままでの在庫の取得方法に、年月日=指定日を付け加えればいいだけ!
 っていう主張をするわけよ、

 だから、ウィリアムのいたずらさん、
   その日の終わりに前日のレコードを全部とってきて、
   翌営業日(これは求められるメソッドがある)用に
   商品台帳テーブルにセットするプログラムをつくって!
 簡単でしょ、「Actionメソッドから!」 insertを発行すればいいだけだから。
 というわけよ!

-----

 おいおいおい、(ActionメソッドにSQLを直接書くことも問題だけど、それより)
 そのテーブル、何レコードになるんだよお!
 (つまり、商品が1万レコードあったら、毎日1万レコードずつ増えるのね。。。1年で約300倍?)
 (ちなみに、業種は、衣料品関連です。だから商品マスタは大きいけど、そんなに、毎日売れません)

 (その会社の社員に)計算させたら案の定

「1ヶ月半で、ハードディスクがいっぱいになります!だめです、日次在庫は、できません。」

 ちがうだろー!だめなのは、日次在庫じゃなくって、お前の考えだろー!

 その後、ウィリアムのいたずらが、毎日悲惨な生活になったのは、いうまでもない。

----

 もう、終わった話ですけどね。

 ちなみに、昨日のブログで、「わけわかんねえーっていうか、ロジック合わなくなっちゃって!」というのは、この話のつづきで、でてくる話です。こんな調子で、仕様変更ごとに、テーブルに項目追加したら、正規形がくずれちゃって、そのうち、ロジックがあわなくなってきちゃうのよね。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする