5 years know-how of RSpec driven Rails app. development. 2011年07月17日(日) (大ホール) 概要 Ruby on Railsを使ったプロジェクトにおいて、RSpecでテストを書きながら開発を進めていくノウハウについてお話しします。 現在、Railsを使った開発プロジェクトでは「RSpecなどによるテスト駆動開発をしたほうがよい」という考え方が極めて一般的なものになっています。RailsやRSpecのツールとしての使い方を照会している、書籍や良質なWebサイトも数多く存在します。 それでも、テストしやすい設計や、メンテナンスしやすいテストの書き方などのノウハウには唯一の正解などがあるものではありません。RailsやRSpec自体やそれを取り巻くテスティングツールもどんどん変化していきますし、方法論も変わっていきます。 この講演
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
railsでテストコードを書いている際に、次のようなコードが多くあった。 assert_equal [1, 2, 3], assigns(:users).map(&:id) result = User.find(:all, :conditions => ["school = ?", "Hoge"]) assert_equal [2, 3], result.map(&:id) 面倒だ なので、Array#fuzzy_equal?を使って次のように実装。 def assert_found(expecteds, *options) if block_given? actual = yield else actual = options.first end if options.last.is_a?(Hash) && options.last[:ordered] assert_equal expe
RailsでActiveRecord（DB）のトランザクション処理をテストする際のメモ。 トランザクション処理 簡単な例として以下のコードを考える。 class User def destroy_with_transaction User.transaction do destroy raise end end end テストコードを書く User#destroy_with_transactionは必ず例外が起こるので、トランザクションの働きで、レコードは削除されないことになる。よって、テストコードは以下のようになる。なお、フィクスチャとしてusers.ymlがあるとする。 class UserTest < Test::Unit::TestCase self.use_transactional_fixtures = false fixtures :users def setup @bob
vimでrubyのテストを編集しているとき、テストメソッドごとに結果を確認しながら書き進めたいことなどないでしょうか。 ruby test/unit/hoge.rb -n test_fuga でテストメソッド単位の実行はできるけど、テストケース名が長かったりするとかなり面倒・・・ ところが、そんな悩みを解消してくれる子に出会いました。 GitHub - janx/vim-rubytest: Run ruby test in vim vimで編集中のテストをその場で実行できるプラグインです。 install $ git clone git://github.com/janx/vim-rubytest.gitで落として、 plugin/rubytest.vim を ~/.vim/ に配置するだけです。 (READMEには 'Copy all files to your ~/.vim direc
script/generate mailerでgenerateされるテストコードの@expectedはTMailのインスタンスらしく、生すぎなことがあります。 というわけで、お手軽にテストする方法をぐぐりました。 via http://sablog.com/archives/2006/03/14/how-to-test-actionmailer-in-ruby-on-rails 1 class SampleMailerTest < ActionMailer::TestCase 2 tests SampleMailer 3 4 def setup 5 # テスト時に配送したメールの配列を保存する。 6 ActionMailer::Base.deliveries = [] 7 end 8 9 def test_welcome 10 to = "satoko@s21g.com"
参考： http://www.yotabanana.com/lab/20060505.html http://blog.masuidrive.jp/articles/2006/07/03/gettext http://kdl.weblogs.jp/kuwano/2007/03/post_dc15.html http://d.hatena.ne.jp/GegegeMokeke/20070616 http://b.hatena.ne.jp/t/actionmailer?mode=rss&sort=hot&threshold=5 実際、get-textを入れて、initしても、直には働かない。なので、ここをいじった ・C:\ruby\lib\ruby\gems\1.8\gems\gettext-1.10.0-mswin32\lib\gettext\rails.rb in 444 を変更（実際、こ
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く