第29章 xUnitのパターン

[at-grandpa]

xUnit系のフレームワークのパターン

[at-grandpa]

アサーション

• 真偽値で正しいコードかを判断し、自動で検証を行う
• assertTrue(rectangle.area() != 0) こういうのはよろしくない
  • null以外を返せば通ってしまうので
• 頭で実装を想像してはいけない！
• privateな値を検証したい場合、それは設計の問題がありそう
  • テストもかなりの実装依存になってしまう
  • privateのリファクタリングを行ったら落ちてしまうからだ
  • publicな振る舞いのみでテストするのがよい
  • ホワイトボックステストを書きたくなるのは、設計を改善する良い機会だ

[at-grandpa]

フィクスチャー

• 複数のテストでつかう共通のオブジェクト
  • setup内で生成したオブジェクトをインスタンス変数に入れる
• 重複があると？
  • 修正が面倒
  • だけど、アサーションの近くに書いてあるのでわかりやすい
• setupに引き上げると？
  • テストはシンプルになるが、setupの内容を覚えておかなければならない
  • どちらが良いかは場合による

[at-grandpa]

外部フィクスチャー

• 外部リソースのフィクスチャーの解放はどうするか
  • tearDownをオーバーライドし、そのなかで解放する
• テストが終わったら元の状態に戻そう

[at-grandpa]

テストメソッド

• テストケースの管理の方法
• テストメ ソッドが長く複雑になってきたら「よちよち歩きゲーム」を始めるときだ
  • 最終ゴールに向かう一歩を示す、最小のテストメソッドを書くこと
  • テストメソッドの長さは３行を目指そう
  • テストメソッド内の擬似コードを日本語で書いてみよう

[at-grandpa]

例外のテスト

• rescueを使って、rescueされなかったらテストが失敗するようにする
• 擬似コードは以下

begin
  test_method
  true.should eq false
rescue
end

• あんまりつかわんかも
• expect_rasesがあるからな

[at-grandpa]

まとめてテスト

• テストスイート内包テストスイートを作る
• あんまり現代ではなさそう

[at-grandpa]

この章で得た知見

• アサーションは「それ以外が来たらfail」という書き方をしよう
  • テストの主張したいことがより伝わる
• privateの値を確認したかったら、設計がおかしい感じ
• 実装を頭で考えつつテストを書いてはいけない！
• setupに引き上げるのは場合による
• テストコードの前に擬似コードを日本語で書いてみる
• ３行のテストを目指す