Software developmentにおけるテスト。
テストのメリット。
- 挙動をプログラムとして記述しておくことでエラーを起こす変更を防ぐ
- 動くdocumentationとして、理解しやすくなる
- アップデートによる変更を検知しやすくなる
- 望む結果が記述されているので、変更を加えやすくなる
などの利点がある。 各言語やフレームワークでテスト拡張が存在する。Ruby → RSpecなど。
プロダクトコードを書く → テストコードを書くことが多いが、最初にテストを書いて開発を進めるスタイルがある。 新規に行う開発だけでなく、バグの修正にも有効。
- 最初にバグを再現するコードを書く。これは失敗する、などとコミットメッセージに書いておく。
- バグ修正/リファクタリング、テスト/プロダクトコード修正を混ぜない。わけわからなくなるから。
- 日本語で検証する内容を書く。もちろん、意図を明確に伝えられる英語力があれば問題ない。単にAdd, Fixとかレベルの語彙しか使えないので、実用的ではない。
- テストのネスト、レベル感を合わせる。
- 例の値であることを示す。
- スタブ
- 指定された挙動をする機能。任意の値をテスト対象に与えて、出力を固定し検証できるようにする。受信メッセージのテスト
- モック
- (スタブの機能) + 処理中の検証機能。送信メッセージのテスト。引数の検証や回数の検証の機能が必要
- スパイ
- (スタブの機能) + 記録機能
モックオブジェクトはリアルタイムにコンポーネントへのアクセスを検証する。 事後に検証してればスパイ、事前に期待値をセットして検証してればモック。
- 受信メッセージのテスト
- オブジェクトがメッセージを受け取ったとき適切な返事をするか
- 受信メッセージのテストをするときは注目しているオブジェクト以外のオブジェクトは偽物を注入し、テストの成功不成功が注目オブジェクトの実装のみに依存させる
- 送信メッセージのテスト
- オブジェクトが副作用のあるメッセージを送信するとき、適切な引数・回数で送信しているか
- 送信メッセージのテストをするときはメッセージの受け手を偽物にすり替えておき、この偽物にメッセージの引数や呼び出し回数が想定通りか検証する
- AAAパターン
- 準備(arrange), 実行(Act), 確認(Assert)
- ただしく設計されていれば、確認フェーズは少なくなる可能性が高い。APIとして抽象化されているということだから
テストの方法の本。
クリーンなテストコードの書き方。