Editor's Notes
- \n
- \n
- \n
- \n
- \n
- ユニットテストの説明に前に本講義で多用されるオブジェクト指向というものについて説明しておこうと思います。\nオブジェクト指向とは何か?  というとよくある説明として「モノを中心にしたプログラミングのことだよ。 $apple->color = 'red'; みたいなね」 のようなものを見かけます。\n実際にそれは正しし、分かっている人には分かり易いのですが、分からない人にとってはただでさえ分からないところを一層煙に巻かれる状態になり易いので、別のアプローチから簡単に説明します。\nデータ構造とアルゴリズムをワンセットにした単位で扱うプログラミング手法のことです。構造体に変数と関数ポインタをセットにしたものだと思えば良いです。\nその関数ポインタで呼び出した内部で、その構造体の変数を"$this"として直接アクセスできるだけですね。PHPで言う場合、構造体ってハッシュのことだと思えば良いです。\n以下のコードは配列とクロージャを使ってイメージを表現したコードです。\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- 人間さんはテストしないですか?\n
- \n
- \n
- 結合テストで確認できるのはインターフェースが\n一致しているということだけです。\n\n
- ユニットテストっていうのは単体テストのことです。ただし、ここではユニットテストと言う場合、オブジェクト指向プログミングにおけるxUnitを用いたクラス単位のユニットテストのことを指します。JavaならばJUnit、.NETならば NUnit、PHPならばPHPUnitを使います。\n\n
- \n
- \n
- \n
- プログラムとして保存する「テスト仕様書」であり「エビデンス」であり\n「プログラムの使い方を説明するドキュメント」であると考えれば良いです。\n他に、「無駄に複雑なコードが書けなくなる」というメリットも有ります。\n最低限「UnitTestが書けるレベルのコード」ということが保証されます。\n
- 3つ目は気になるところだと思うのですが、\nクラス境界、システム境界のインターフェースに齟齬が\nあるという種類のバグは検出出来ません\n
- \n
- \n
- こんなコマンド打つと実行できるよ\n
- \n
- \n
- Unitテストは単体テストなので "クラス単体" をテストします。\n依存を排除したクラス設計をしなければなりません。\n\n\n
- 依存を排除する理由はつまるところ、これです。\n
- モックを作るコードを説明する。\n・メソッドの入力の検証\n・出力の固定\nについて説明する\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- DBWrapperをモックにして、コンストラクタの引数で渡しています。\n\nモックにして期待通りのSQL文が渡されることの確認と\nDBが返した値をそのまま返却することを確認しています。\n図中では畳んでますが、getTestCDで配列を定義しています。\n\n
- \n
- FileManagerをモックにしてセッタで設定しています。\nまた、自身のfindに対する依存があるため、\n自身をモック化してfindが返す値を固定しています。\n\n
- \n
- エスケープのテスト\n\n何にも依存しないユーティリティのようなものなので、ままテストできます。\n
- ラッパーのことです\n
- \n
- \n
- \n
- 引数で渡すにせよ関連するクラスはメンバ変数にしてしまうのが、\nUnitTest的には便利だし、オブジェクト指向の設計的にも理にかなってることが多いはず。\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- 人間さんはテストしないですか?\n
- \n
