ぼうメモ帳

2006-08-29

単体試験(1)

| 単体試験(1)を含むブックマーク

少しずつ書いていく。

最近、特に単体試験のための自分なりのデザインパターンに対する考えをまとめている。私にとって、メソッド単位試験と、クラス単位試験が単体試験になる。メソッド単位試験とは、ある入力に対するメソッドの出力が、想定していたもの(ここでは仕様と呼ぶ)と合致するかを調べることだ。なお、オブジェクトプロパティや外部環境からの入力はメソッドの入力に該当し、プロパティの変更や外部環境への出力などの副作用は出力に該当する。

簡単な例を示す。

int add( int a, int b ){
  return a + b;
}

このようなメソッドが与えられたとしよう。このとき、メソッドの入力は「a」「b」となり、メソッドの出力は「a+b」の計算結果となる。

もう一つ例を示す。

int property;
int add3AndPrint( int a, int b ){
  System.out.println(a+b);
  return property + a + b;
}

このようなメソッドとプロパティが与えられたとする。このとき、メソッドの入力は「a」「b」「property」となり、メソッドの出力は「a+b」「property+a+b」となる。

単体試験王道は、このメソッドの入力に対するメソッドの出力が正しいかを確認することにある。そして、単体試験のためのデザインパターンは、単体試験を効率的に行うための、機能プログラム試験対象プログラム)の書き方と、試験プログラムの書き方だと考えている。すなわち、試験のためのパターンは、次の2種類に分類されるというわけだ。

トラックバック - http://d.hatena.ne.jp/susumu/20060829

2006-08-24 このエントリーを含むブックマーク

やっと、今の会社就職した理由が分かったw

いままで、会社としてデカイからとか、たまたまオイシイ話が転がってたから、というのを理由にしてたけど、本当の理由が分かった。しかも、なんで大学院での研究を開発環境研究に焦点を当てたのか。また、プログラミングが好きといいながら、プログラムそのものの開発ではなくフレームワークの開発がすきなのか。何かしようとすると、ツールの開発から入ってしまうのはなぜか、という答えまで見えてしまった。

答えは、プロセスに興味があるから。ただこれだけだった。

今の会社就職したのは、大規模システムを開発するときのプロセスに興味があったから。

大学院研究で開発環境に焦点を当てたのは、開発のプロセスを構築してみたかったから。

フレームワークばかり開発しようとするのは、ソフトウェア開発での効率的なプロセスサポートするツール群が欲しかったから。

何かしようとするとツール開発から始めてしまうのは、その何かのプロセスを追求してみたいから。

すべては、プロセスに興味があり、プロセスを追求することに興味があったから、今の自分があることに気づいてしまった。となると、今の職場は俺にはあわねえ… でも、まだプロジェクトマネージメント関連の部署には行きたくないしなあ。*1

しまった、酒の勢いで書いたものの、よくよく考えてみたら、モデルについても全く当てはまることだったorz

*1プロセスを追求するだけなら、べつにコンピュータ業界にこだわらなくても良いじゃんという答えには気づかなかったことにしておこう

トラックバック - http://d.hatena.ne.jp/susumu/20060824

2006-08-17

今日もタクシー

今日もタクシーを含むブックマーク

池袋からタクシーを拾うのは今週で二日目。1回2000円の出費だから、残業1時間分の稼ぎがパーになることになる。正直、タク券が欲しかったり。

で、今日の運転手さん、なかなか話し好きな人でした。もう50過ぎているであろう年配の運転手で、東北から半年前に出てきたそうです。詳しいことは聞けませんでしたが、かなり苦しい生活をしている模様でした。

最近、とみに思うことがあります。

かなり年配の方が安いであろう給与で働いていることです。今日タクシーの運転手もそうですが、極めつけは、駅前の松屋で働いているおばあちゃんです。年金暮らしをしていてもおかしくないような初老の方が、松屋バイトですよ。正直、信じられません。

毎月給与から少なくない額が税金として天引きされています。もちろん年金もこれに含まれます。そんな方々を見ていると、この天引きされているお金はどこに流れているのか、ちょっと気になる今日この頃です。

リーダ代行中

リーダ代行中を含むブックマーク

自分の仕事が進みませんorz

でも、ビールは旨いです。

とりあえず、急ぎ、戦力の補充をお願いしたいです。

自担当に戻れるのはいつになるのかなあ…

メモ

| メモを含むブックマーク

以下、なんとなく最近感じているメモ。そのうち真面目にまとめます。

  • 試験を効率的に自動化するためなら、美しい設計なぞ端からあきらめる。
  • UTは100%の自動化を目指す。そのための設計を行う。
  • UTはメソッド単位試験を行い、自動化する。
  • メソッドの種類を次の3種類に分けて設計・実装を行い、自動かもパターン化する。
    • 外部接続メソッド
    • 自己完結型メソッド
    • シーケンスメソッド
  • 外部接続メソッド
  • 自己完結型メソッド
    • 外部のクラスや、環境などにアクセスする必要がないメソッド。
    • 可能な限り、ステートレスが望ましい。ステートレスなら、試験は境界値に対する入出力のみの確認で可能。
    • ステートレスでない場合は、ステートを確認する手段を用意しておき、試験実施前のステートを入力として扱い、試験実施後のステートを出力として扱う。
  • シーケンスメソッド
    • 他のクラスへのアクセスや、多量の分岐、ループなどが存在するメソッド
    • 試験前は、シーケンスを確認できるスタブを気合で作りこむ
    • スタブが管理すべき情報としては、こんな感じ。
      • メソッドの呼び出し順序
      • 呼び出した際の引数の値および戻り値(例外も含む)
    • 試験プログラムでは、スタブの呼び出し順序と、引数の値を全チャックする。
  • スタブを作りやすいような構造
  • 1つのメソッド内の分岐やループは、分岐の爆発を防ぐため、3ネスト以上しない
  • 試験項目表はチャンと作る。JUnit試験する場合、項目番号と、テストメソッドの名前を一致させると楽。
    • 試験項目が012である場合、JUnitのメソッド名はtest012にする。
    • 試験目標に必要な項目は、最低次の3つ。
      • 試験内容が簡潔に表される試験項目名。
      • 前提条件(環境とか入力とか)
      • 確認項目(出力値とか出力値とか出力値とか)
    • 一度作った試験項目は消さない。変更したい場合でも、新規に項目を起こす。必要なくなったものは、グレーアウトするなり、コメント化するなりして、絶対に消さない。そのうち、役に立つときがある。
  • 試験プログラムは、ループ、分岐が入ったら負け組
  • オブジェクトには、一致判定のメソッドを準備する
  • 【過激】フレームワークでない限り、privateメソッドを使うことは、負け組み。どうせ自分しか使わないメソッドは、逆にprivateにする必要なし。
  • 入力値、出力値の生成は、1箇所で行う。そうすれば、入力値、出力値の齟齬によるバグは発生しない。
  • 【過激】設計書がチャンとある場合は、クラス名とかにはこだわるな。採番で十分。むしろ、そのほうが、設計書との連携を密にできる。
  • クラスの役割を意識して、クラス分割に励む
  • UTのステップ数は、本番プログラムステップ数の3〜5倍ぐらいが密度的にちょうど良い。少なければ、抽象化しすぎか少なすぎ。多ければ、試験のやりすぎ、時間の無駄
トラックバック - http://d.hatena.ne.jp/susumu/20060817

2006-08-07 このエントリーを含むブックマーク

今日もまた終電で帰宅。。。

トラックバック - http://d.hatena.ne.jp/susumu/20060807

2006-08-03

健康診断

健康診断を含むブックマーク

結果が帰って着ました。今年は昨年よりも項目数が少ないわりには、要所見が増えてる!!

  • 肺  :硬化巣(なんで?)
  • 尿検査蛋白+血orz
  • 肝機能:昨年よりも大分増加
  • 脂質 :上限ギリギリ 1とか2しか下回らないw
  • 貧血 :基準値上限超えorz

こうみると、来年当たりA2→A3領域へ突入しそう。近々病院にでも行ってみるか。

トラックバック - http://d.hatena.ne.jp/susumu/20060803
276423