Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
※2011/11/08 コメント欄で指摘を頂いた箇所を加筆修正しました。また、割と古い記事ですので最新の情報は Fabrication を参照することをお奨めします。 これを作ってるとき、machinistとmachinist_mongoを使っていたんですが、試しに前々から気になっていたFabricationで書き換えてみました。README書いてあることをいくつか実際にやってみたのでメモしておきます。割と使いやすかったです。 何に使えるの 下記をサポートしてるそうですので、Mongoid使えます。やった! Plain old Ruby objects ActiveRecord objects Mongoid Documents 使ったもの Fabrication…本日のメイン Faker…嘘データをどんどこ作ってくれるやつ QuickStart & 使い方 Gemfile Rails/M
めも FGはdefineの仮引数周りが無駄 (blueprintで改善) FGはinstanceをフラットに管理しすぎ FGのsequence(next)はイケてる FGはAR前提 Machinistは定義がイケてるが、名前がダサイ(make_unsaved) Machinistはメソッド名が衝突しそう(makeはアカン) Machinistはinstanceをクラス毎に分類できるが、Shamレベルまで落ちるとフラットになる片手落ち感 Daddyの使えなさは異常 FGの継承はどうやるの?(-> :parent) FG.blueprint は :parent を理解してくれない 試行錯誤 Factory.sequence :login do |i| "login#{i}" end Factory.define(:user) do |user| user.login {Factory.next
概要 Machinistは定義された条件下でテストデータを生成するプラグイン・gem。 DatasetはRubyのコードで記述したテストデータをDBに読み込むプラグイン・gem。 この2つを組み合わせることで(比較的)メンテナンスのしやすいfixtureの代替を構築することが可能になる。 流れとしては、Dataset上でMachinistを呼び出して複数のデータを生成して、それをDBに流し込むという感じ。 メリットは、 条件下でランダムなデータを生成してくれる(「特定のデータをfixture上に作って読み込む」というようなことも可能) リレーション先のデータも適宜生成してくれる(素敵!)。 デメリットは、 データがランダムなので、全条件を必ずカバーするのは苦手&毎回同じデータが入ってくるとは限らない(回避できるかなぁ) fixtureに依存した書き方をしていると大幅な書き換えが必要かもしれ
Rails のテストを書いていて、フィクスチャはのちのちメンテナンスに苦労しそうだから FactoryGirl を使ってみた。 FactoryGirl についてはここが詳しい http://www.func09.com/wordpress/archives/532 上のページの例にあるとおり、中間テーブルを使うようなケースでテストデータを定義するのに便利らしい (公式ページ?でもそのように宣伝していた) のだが、中間テーブルが不要な has_many/belongs_to の関係を定義するときに、 association を親子どちらに書くかでハマってしまった。 すぐ動かせるコード例がなくて恐縮だけど、 FactoryGirl で has_many/belongs_to な association を定義するときは、必ず子のほうに親の Factory を書かないといけないっぽい。このスレッ
休んでいるうちにずいぶん時間が経ってしまいましたが、10/31のOSCにてお時間をいただき、Railsの昨今のテスト事情について紹介させていただきました。普段から申しているようにCucumberとRSpecをぐいっと推しています。 Rails testing environment, 2009 fallView more documents from Kyosuke MOROHASHI.あとはRSpec方面で、subjectやitsの使い方について、使いながら考えているようなことを書いています。 前にオブラブ方面でCuctomMatcherの話をしたときに、簡単なCustomMatcherを量産するのはだるいんじゃない?という懸念があったんですが、その一つの解としてits()はありかなー、と。使い分けはこんな風になると思います。 CustomMatcher作る 検証内容が複雑になるとき エ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く