元に戻す

1/6に向けて調子を元に戻す。

DailyHit

26 failureだったのを2にした。見た目のリファクタリングで変更漏れみたいなのを検出するのにテスト役に立っている感じある。

31ぐらいあるけど本当に必要なもの絞って書いたほうがよさげ。今日は運動してから続きやろうかな。

参考になる

generatorの中身ちゃんとみないと、generatorによって生成されるGruntfile.jsとかが違って、期待した動作しなくてハマった。生成されたものをもっと観察しないとあかん…grunt-bower-installなんて便利だけど、、、

以下好きな部分抜粋

だから、テストは必ず書くという考え方はばかげている。アプリケーションコードと全く同じで、コストとリターンを見極めながら必要に応じて書く、が正しい。

一昨年の2012年、テストが1つもない状態から書き始めた。テスト全然書いたことがなかったので勉強しながらだった。 RailsはほぼAPIサーバーだがフロントエンドのHTMLはくのにも使ってる。 plainなBackboneだけ使っていて便利なプラグイン使っていない。

どこを重点的にテストすべきか見据えず、とりあえず色々書いたこと
フロントエンドのJavaScript/CSSがRailsのバックエンドと完全には切り離せていなかったこと
- うまくハマるテスト用のライブラリが探せなかった
- JavaScriptライブラリの依存関係はbowerを使って切り離した
Viewがおおはばに変わることが多いのに、DOMやHTMLの構造にかなり依存しているJavaScriptのテストをいっぱい書いてしまったこと
- テストのしやすさみたいなものがまだ掴めていなかった
- テストの費用対効果の感覚がまだ掴めていなかった
- テストしやすくなるようなライブラリなりなんなりを最初に取り入れたり作ればもっとうまく書けた
もっと早めにe2eテストを書くべきだった
- 費用対効果高い
- ユニットテスト書いても組み合わせたとき動かないとかあった
テスト環境構築の自動化
- Chefで頑張ろうとしたら覚えることが結構多かったりコミュニティレシピでハマったりして今も模索中

とりあえず色々とテスト書いたこと
- こういうの書くと後々腐るみたいなの覚えられた気はする
- テスト書きづらいコードが大量にあったおかげで、こう書くとテスト書きづらいというのを体感した
UIの変更に耐えやすいテストの書き方とか少しうまくなった

rake specすると今こんな感じ

Finished in 11 minutes 26 seconds
1307 examples, 26 failures, 52 pending

実行時間かかりすぎですね。多分これもうまく書けばもっと短く出来る。ばっさりすてて書き直したい欲に常に駆られている。

javascriptのユニットテストも同じぐらいの数あるけど、テストコードの品質が悪いのと、費用対効果の悪さからもう書いてないし実行してない。今度ざっくり削除したい。書き直すのはありだと思う。今ならもっと上手く書ける。

コアな機能が追加されたら、追加された部分で、確実に動いて欲しい部分だけfeature書いていきたい。