やる気が持続するテストの書き方 - Tlab Blog
こんにちは。nayです。TDDと出会ったのは6年以上前ですが、最近、やっと"友達"になることができました。 テストを楽しく積極的に書く心境になれるかどうかは、気だてや価値観や根性の問題ではなく、テクニックの問題であると思います。そこで、テスト嫌いの私がどうやってTDDと友達になれたかを、３つのポイントに絞ってご紹介したいと思います。 1. 関心事だけをテストする 2. DRYにする 3. RSpec 私がテストが嫌いになった理由の一つは、コード変更時にテストが足かせになることです。出るべくして出たエラーはありがたいのですが、関係ない部分で大量にエラーが出ると直すが大変で嫌になってしまいます。また、直そうとしたときに、テストのコードが読みにくいと、難行苦行に直面することになります。最初の２つのポイントは、このようなテストの「丈夫さ」と「読みやすさ」に関わるコツです。 関心事だけをテストする
RSpec on Rails のバグっぽい挙動について - milk1000cc
RSpec on Rails で redirect_to のテストを書いていると、 ActionController::MethodNotAllowed Only get requests are allowed. や ActionController::MethodNotAllowed Only get, put, and delete requests are allowed. といった、謎の例外が発生することがあります。 簡単な (無意味な) Rails アプリを作りながら、説明します。 $ rails hoge $ cd hoge $ cd vendor/plugins $ git clone git://github.com/dchelimsky/rspec.git $ git clone git://github.com/dchelimsky/rspec-rails.git $
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
David Chelimsky RSpec 1.1
The RSpec Development Team is pleased as glug (that’s kind of like punch, but more festive) to announce RSpec-1.1.0. Thanks to all who have contributed patches over the last few months. Big thanks to Dan North and Brian Takita for their important work on this release. Dan contributed his rbehave framework which is now the Story Runner. Brian patiently did a TON of refactoring around interoperabili
はてなブログ | 無料ブログを作成しよう
ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
Exception Notifier Pluginを導入して分かったこと - 世界線航跡蔵
運用環境でRailsの Exception Notifier を使ってる。 で、アプリケーションでUnhandledな例外が発生するとメールが飛んでくる訳だ。分かったのは、運用段階まで残るエラーは結局nilに対するNoMethodError、つまりは所謂「ぬるぽ」が多いということ。だから、これからはモデルがnilを返した場合、Viewにnilが渡った場合の挙動についてもっと重点的にSpec記述すべきということだ。 もう1つ言えるのは、今の開発体制においては言語の柔らかさは障害になってないということだ。動的型付けのメリットが活きていて、デメリットはちゃんとRSpecを記述することでカバーできている。「ぬるぽ」はどうせJavaやC#程度では、「言語の固さでカバー」という訳にはいかないものね。型システムの固さでカバーしようとするなら必要なのはJava/C#程度じゃなくてMaybeモナドとかそうい
Railsのテスト環境を改めて- MacOSX / RSpec / ZenTest / Growl:TKMR.blog.show
最近Macの再インストールしてから開発環境が中途半端だったので、Railsのテスト環境を改めて整備、のメモ 1) Rails開発環境は入っている 2) RSpec入れる % sudo gem install rspec 3) ZenTest入れる % sudo gem install ZenTest 3) diff-lcs入れる % sudo gem install diff-lcs 4) 自分のRailsアプリのディレクトリへ移動 % cd /RAILS_ROOT/ 5) rspec on rails入れる % sudo ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_1_0_5/rspec_on_rails 6) RSpec関係ファイルのセットアップ % ruby script/gen
Young risk taker.: [Rails] Unit::TestかRSpecのSpecファイルを実行しボトルネックとなるクエリを書き出すSlowQueryLoggerを作った
久々に面白いモノを作った。 SlowQueryLogger RailsではActiveRecordを利用してガンガン富豪プログラムを書きがちなため、適切にインデクスを張っていないとすぐに重たくなるので、Rails中で発行された遅いクエリをロギングするプログラムを作った。 ActiveRecordの参照系クエリを発行するメソッドをEXPLAINにより実行解析情報を取得しロギングしてから通常の参照クエリを発行するように拡張し、Rails付属のUnit::TestのfunctionalテストまたはRSpecのコントローラーのSpecファイルを実行する。最終的には、filesortか一時テーブルを使用しているクエリがログファイルに書き出される。 つまり、functional testを定義したファイルかRSpecのcontrollerのスペックファイルがあれば特に何も用意する必要はない。 現在My
RSpecにおけるコンテキストをまたぐ共通部分 - 世界線航跡蔵
先日書いた SeleniumRC spec の中で使ってたテクニックが最近、会社で流行ってる。 2007-12-04追記: このテクニックはRSpec 0.8以前のために開発しました。RSpec 1.0以降ではshared behaviourを使いましょう。ただ、RSpecをいじくる技法の基礎として参考にはなるかもしれません。 コンテキストにおける共通の初期化処理は勿論、setupやcontext_setupに書けばいいんだけど、問題は複数のコンテキストにまたがる共通の初期化処理。あるいは、modelのspecでfixtureを設定したり、controllerのspecにおいてコントローラー名を指定したり。 これらって、いちいち書くのがなんかDRYじゃない気がする。特に、1つのmodelに対するspecがcontextから構成されるとき(諸橋さん方式。contextという言葉の意味合いから
SeleniumRC spec - 世界線航跡蔵
Selenium on Railsもいいけど、やっぱり、Rspecに全部統合したいわけですよ。あと、全部Rakeから自動でやりたい。で、SeleniumRCの呼び出しをRSpecに統合してみた。 2007-03-05追記。@selenium.stopを忘れてました。 2007-11-20追記。RSpecの新記法/新実装に対応した 新しいバージョン を作りました。 script/selenium/にselenium-server.jarを置いておいて、 def selenium_context(*args, &block) context(*args) do context_setup do @selenium_pid = Process.fork do $stdin.reopen(File.open('/dev/null')) $stdout.reopen(File.open(File.j
[rails] 実践RSpec on Rails - コントローラとモデルのBehaviourを書く
先日RSpec on Rails0.7(0.7.1も)が出ました。 まだまだ枯れていないので実際のプロジェクトで採用するのは難しい面もありますが、isoration from Databaseを支えるmock/stub frameworkや、isoration from viewsは強力なので、それほど影響の無い作成済みの社内アプリにRSpec on Railsを適用してみました。 maihaさんがやっておられるように、自作で作るのもすごく楽しそうなのですがとりあえずは使ってみます。mock/stub frameworkの実装の詳細をあとでみる。 BBDでは、Behaviourを書いてからコードの実装を行うのですが、今回は以前にうみがめで作った社内用情報共有ツールBasecamp(某signalsのパクリ)にBehaviourを書いていくことになります。 BasecampのSpec 社内で
Yellow between Red and Green - 世界線航跡蔵
id:yuki_neko_nyan さんや id:moro さんが言う「仮実装に対するマーカーが欲しい」というのは実際の開発に置ける利便性という意味では分からないではないんだけど、捉え方は私の考えとは違う。 つまり、こういうことだ。 「仮実装は仮ではありません」 仕様は、少なくとも機能要件を満たすための要素に関しては自動実行可能な形式で書かれているべきだと思っている。だから、t-wadaさん曰く、「redフェーズは仕様の定義段階」なんでしょう。 仮実装でGreenになっているというこという状況は、その仕様を満たす極めてシンプルな実装ができたということ。定数を返しつづけるようなメソッドを書いてGreenになってしまうなら、そのモジュールは今はそういう仕様である筈だ。 だから、そこで言うべきは「仮実装に対するマーカーが欲しい」ではなくて「仕様の定義の不足に対するマーカーが欲しい」だと思う。 些
RSpecって何? - もち
前々から気になっていたので，ググって見た．そしたら，速攻でかくたにさんの書いたドキュメントが見つかった． http://kakutani.com/trans/rspec/TUTORIAL_ja.html う〜ん，振舞駆動開発…TDDみたいなもんね…． Pan% echo "1.should_not_equal 1" > one.rb Pan% spec one.rb /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.1/lib/spec/expectations/should/base.rb:17:in `fail_with_message': 1 should not equal 1 (Spec::Expectations::ExpectationNotMetError) from /opt/local/lib/ruby/gems/1.8/gems/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Rails, Ruby & Prototype ramblings—Lourens Naudé