Rails勉強会@東京第40回にいってきた
今日はいつものクオン社でRails勉強会@東京に参加してきました。
11:00くらいにおきて12:00くらいに家をでて、だいたい13:00くらいに会場到着。
人数が多くてちょっとせまい感じでしたが、それがまたワイワイ感を醸しだしていてよかったとおもいます。
ust番長
Rails勉強会でust番長をはじめて3回目になりますが、セットアップもささっとできるようになってきた。
でもustのためにPC2台持ちはやっぱりキツい。何とかならないものか。
今回もust用に有線LANを用意してもらえたので配信は問題なくできました。前回もあったんだけど、途中で画面の下半分の映像がめちゃくちゃに乱れることがある。なんでだろ？Webcamのドライバのせいかな？
前半セッション - Merb on GAE/j(Google App Engine)
Merb AppおGAE/jで動かすお話。ust配信が忙しかったのでメモが取れなかったorz
詳しくは他の方のエントリーをみてね。
http://d.hatena.ne.jp/hs9587/20090419
後半セッション - RSpecとかテストとか
view のテストはかくの？
→かく。Rspecでかく
→conrollerで仕事してないから
更新系のロジックはmodel、参照系のロジックもmodelどうやって使うかを記述しているのはview。なのでviewのテストをやる。
→なにをみたいのか確認するためにテストをかく。
→controllerを回避してviewのテストをかく？
→出力からテストするかんじ。
→出来上がったものに対するテストではなくスケッチみたいなかんじで
t-wadaはテストをすてる
→メンテの重荷になったらテストを捨てていく。
→正常系は残す→セーフティーネットとしてつかう
Cucumberをいつからつかう？
→永和の人はテスト大好き
→最初からCuを書くのは大変
→ひとつふたつ機能かききってからCuを適用
デザイナがはいったら？
→CSSだけですまないところは局所化できる
モックを書くのがめんどくさいということは、設計がわるい
http://www.patmaddox.com/blog/you-probably-dont-get-mocks
- 正常系はテストファーストするためによい
- 異常系は再現性をたかめるためによい
→のちのちまでとっておくことが多い
スローテスト問題→現在のTDDの課題
テスト資産が増えてくると一回のテストに掛かる時間が増えてくる
Autotest
タイムスタンプを比較して必要なテストだけを自動的に実行するツール
Javaの世界では研究が進んでいる
過去の失敗率とか履歴からテストの実行順を考える
テストにバグがあった場合どうすんの？
ミューテーションテスト
Heckle：実装が壊れたときにテストが壊れるかどうか調べるツール
http://www.rubyinside.com/heckle-tortures-your-tests-for-revealing-confessions-339.html
ポイントポイントで実装を壊して、テストが通らなくなることを確認する
バグに気づかない場合が難しい
TDDでペアプロしない場合
- テストファーストで確認しよう
- 似たような間違いがないか調べよう
- テストコードの粒度をちいさく
テストの可読性を確保しつつ、DRYに！それがRuby way by t-wada
created_atを調べたいけどshouldうまくかけないよ
フレームワークの機能そのものをテストしない
RSpecの失敗したときの表示ってまだまだ甘い
見ため的に同じなのに型が違うとか
mockをDesign by Contract仕様の記述に使ってもいいんじゃないの？
- Contractの記述はプロダクトコードに書けばいい
