About Cacher
Web App
Download
Sign In
Sign Up
menu
Cacher is the code snippet organizer for pro developers
We empower you and your team to get more done, faster
Learn More
shimgo
10/27/2016 - 8:37 PM
share
Share
add_circle_outline
Save
RSpec テストガイドライン(自分流)
RSpec テストガイドライン(自分流)
rsec_guidelines.md
content_copy
file_download
Rendered
Source
バリデーションのテストvalid?した後にエラーメッセージを検証する
-> validだけの検証だとどのバリデーションに違反したかわからないため。また、独自のエラーメッセージをつけている場合もあるため。
先に有効となるモデルデータの検証を行い、その後属性の検証を行う
->属性の検証で有効を確認しなければならない場合(例:lengthの検証)に有効なデータが必要になるため
【オブジェクトの状態に着目する方法】
まずはテスト対象の状態一覧をcontextで記述。
その状態ごとに全インスタンスメソッドを記述する。
さらに入力によって結果が変わる場合はcontextを記述する。
オブジェクトの状態を一覧してから各メソッドのテストを書くと状態に対するテストが漏れなくできるが、あるメソッドの仕様を調べようとすれば各状態にケースが散らばる。逆にメソッドを一覧してから各状態を書くとそのメソッドの仕様がわかりやすい。通常インスタンスメソッドの数>状態の数となる。インスタンスメソッドの方が追加されることが多いと思うのでメソッド/状態の階層の方が書きやすい&メソッドの仕様がわかりやすいメリットがある。しかし各状態を表すテストデータの準備がメソッドよりも上の階層で行う必要が出て来る
コントローラのテストにおいて、スコープを使った検索処理がある場合に、その検索結果を検証するとモデルの単体テストとやることが被ってしまうので、そうならないようにコントローラで行う処理の検証をするようにした方が良いのではないか
clear