ayuminのあまり更新しないBlog

筆不精なのでめったに更新しません

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の世界では研究が進んでいる
  過去の失敗率とか履歴からテストの実行順を考える
 

RubyリファクタリングブラウザができたらIDEもいいかも

 コードリーディングにはNetBeansとかつかうといいよ
 コード補完便利だけど出すぎ→もっと空気読んで欲しい

Ruby Refactoring Browser

 http://www.kmc.gr.jp/proj/rrb/

 Fakeit:テストを通すための偽実装

テストにバグがあった場合どうすんの?

 ミューテーションテスト
 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の記述はプロダクトコードに書けばいい