Rails の話。
最近では model のスペックをあまり書かなくなってきた。ほとんど feature spec で済ませている。
feature spec に対する思いをダンプしたくなったのでしておく。
ここにいたるまでの遍歴
- rails 触り始め、テストという概念は知りつつも書き方が全く分から無い
- model spec の書き方を覚える
- model だけをテストファーストで書いたりする、テスト書くの楽しくなる
- BDD を知り feature spec driven で全部の行程で test first で開発するも、テスト書くの辛い
- テスト書くのが面倒になる
- あるチームで、納期が短いけどテスト書かないのはヤバイ、じゃあ後からでも良いから feature spec だけでも書こうという話になる。
- 最低限 feature spec を書けば良いんだ、という気付き
- feature spec 書くの楽しい!!! <- イマココ
主動で確認するのが面倒な部分こそ feature spec
以前は model のスペックをひたすら頑張って書いていたけど、それだと結局、最終的なブラウザ上でのテストを手で頑張る感じになっていた。
データを用意するのが面倒な部分なんかは、feature spec を用意しておくと、動作確認がすごく楽になる。 あと、API を作るときとか、ワザワザ curl 叩くとか面倒だけど spec があると動作確認の代わりとして使えて楽。
ユーザ目線での最低ラインの動作保証
feature spec があるとその機能に関しては動作が保証されるので、安心感がある。
Rails のバージョンアップも、feature spec があると安心して行える。 例えば model のスペックだけだとユーザが触る部分の自動テストが無いことになるので、怖くてバージョンし辛くなりがち。
結合試験的な意味合い
routing も controller も view も model もそれぞれ Unit テストとして単体テストがかけるけど、 それらを全て繋ぎあわせたテストが feature spec というイメージ。
必然的に、ある機能に対する一連のコードを通るので、ちょっとしたリファクタリングをした時の typo だとかにも気づきやすい。
辛さからの解放
プロダクトコードを書きながら仕様を固めていく事が多いので、先にテストを書く方法というのが僕には結構辛かったみたい。
それで最近は、
- ある一連の機能をテストなしでとりあず作る
- それに対して feature spec を書く
- リファクタリング
- 必要があればモデルにスペックを足す
みたいにやってる。 もしくは、データをつくるのが面倒な時などは、先に feature spec を書くことも結構ある。
周辺技術
ちょっと前までは capybara webkit の build が面倒だから〜とかあって敬遠しがちだったけど、 最近は PhantomJS がでてきて、前より楽になった気がする。
最近の流れ
TDD は死んだ、みたいな記事もあったし、そういうのが盛り上がってるのかも、とも思ったり。
気をつける事
必ず失敗する事を確認するようにしたい。偶然他の所で同じ文言が表示されててたまたま通ってたとか、そもそもマッチャーの使い方間違ってたとかよくあるので。
悩み1: テスト実行時間
feature spec が溜まってくると、本当にテストの実行時間が遅くなって辛い。
悩み2: はまりやすい
特に JS が絡んでくると、描画タイミングの問題とかあったりしてハマりやすい。 CI だけ落ちるテストとかあったりして闇が深くなりがち。。
オチ
特に無い