はじめに Web APIを使って様々なサービスと連携するというアーキテクチャはすっかり定着した感があります。みなさんも、Web APIを使ってデータをやりとりするアプリケーションを書く機会も増えているのではないでしょうか。 Web APIを使うアプリケーションの開発では、テストやデバッグをする際のAPIアクセスが悩みどころとなります。本物のサーバを使ったのではテストデータの初期化などに手間がかかりますし、逆にHTTPアクセス自体をスタブやモックを使って間接化してしまうとそれが本当に有効なテストなのか不安が残ってしまいます。 筆者も、仕事やプライベートでのコーディングでこのような悩みに何度も遭遇しました。これらを解決するために開発したのがwwです(wwと書いて'double-web'と読みます)。 ダミーWebサーバ作成ライブラリww(Double Web) wwは、Webサービスの簡単
gemを作ってrubygems.orgで公開する - 橋本詳解 の続き。ArgsPasrerのテストを書いた。 前回testの中身を書いてなかったので。 newgemで雛形を作る時に-T rspecしておくと、rspecのテストコード雛形とそれを呼び出すrakeコマンドが自動配置される。 前回-T rspecしなかったのでtest::unitの雛形ができてしまっていた。 newgem asdfhujiko -T rspec適当に-T rspecしたプロジェクトを作って、そこからtasksディレクトリとspecディレクトリのファイルを持ってきてArgsParser内に配置した。spec内の名前もasdfhujikoから変更した。 testディレクトリ下のTest::Unitも全部削除した。 ディレクトリ内はこうなった ArgsParser |-- History.txt |-- Manife
伴う、というかそれがメインの機能だったりもするわけですが。 少し前、以下の記事でごく単純なOAuthコンシューマの実装を行いました。 OAuthコンシューマの仕組みと実装 〜 Ruby編 - しばそんノート この小さなライブラリの使い方は以下の通りです。 require 'simple-oauth' simple_oauth = SimpleOAuth.new('COMSUMER-KEY', 'COMSUMER-SECRET', 'ACCESS-TOKEN', 'TOKEN-SECRET' ) response = simple_oauth.get('http://example.com/') response = simple_oauth.post('http://example.com/', :foo => 'bar') これで全機能です。*1 getやpostメソッドでは、内部でNe
I'm watching Francis Hwang's talk from RubyConf 2008 titled "Testing Heresies." He discusses his reasons for not using mock objects, and commits a common error when trashing mocks: he shows crappy examples which evidently serve as proof of why the technique sucks. To start, let's look at the two main arguments people make for why mocks suck: They duplicate the code under test Objects can get out o
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
仕事で作っているRailsアプリにCucumberを突っ込んでみました。これは熱い。いやもう十分、お客さんに見せて分かってもらえる気がします。たぶん。もちろん準備は必要だし、受け入れ仕様をすべてお客さんに書いてもらうというのは難しいですけど*1。 とりあえず導入はこちらから。最近はNokogiriが必要です。あとTerminal.appで--no-colorつけずに実行するとTerminal.appがひどいことになるのでiTermお薦めです。 http://github.com/aslakhellesoy/cucumber/wikis/ruby-on-rails 2010-11-10 SEO的に。この記事を書いてから2年、いろんなCucumberの使い方を調べました。そのノウハウを達人出版会にて本にまとめました。よろしければこちらもどうぞ。 http://tatsu-zine.com/bo
久々に面白いモノを作った。 SlowQueryLogger RailsではActiveRecordを利用してガンガン富豪プログラムを書きがちなため、適切にインデクスを張っていないとすぐに重たくなるので、Rails中で発行された遅いクエリをロギングするプログラムを作った。 ActiveRecordの参照系クエリを発行するメソッドをEXPLAINにより実行解析情報を取得しロギングしてから通常の参照クエリを発行するように拡張し、Rails付属のUnit::TestのfunctionalテストまたはRSpecのコントローラーのSpecファイルを実行する。最終的には、filesortか一時テーブルを使用しているクエリがログファイルに書き出される。 つまり、functional testを定義したファイルかRSpecのcontrollerのスペックファイルがあれば特に何も用意する必要はない。 現在My
rcovを使ってて、いちいちHTMLを見ないといけないのが面倒と思ってる人は、是非とも「--gcc」オプションを使ってみよう。 いちいちHTML見るのめんどくせえと思ってずっと前に俺が追加したオプションだが、あまり知られてないようだ。 # a.rb def foo(x) if x >= 3 x+2 else x+1 end end require 'test/unit' class TestFoo < Test::Unit::TestCase def test_1 assert_equal(12, foo(10)) end end テスト漏れの部分が標準出力に出力される。 これでエディタの中で快適にジャンプできるだろう。 $ rcov --gcc /tmp/a.rb Loaded suite /usr/local/bin/rcov Started . Finished in 0.00071
リンクや URL の HTML を生成してくれるヘルパメソッド link_to や url_for をユニットテストで使いたいことがあるかもしれない。これらは基本的にコントローラかビューのコンテキストで使うことが前提になっているから、ユニットテストではそのままでは使えない。次のような工夫が必要になる。 1. ユニットテストの先頭でヘルパメソッドの格納されているモジュールをインクルード たとえば EntryTest というユニットテストで、link_to や url_for が使いたいとする。 url_for は ActionController::UrlWriter, link_to は ActionController::UrlWriter にあるから、 class EntryTest < Test::Unit::TestCase fixtures :entries include Ac
『るびま』は、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 直
システム開発におけるテストの重要性は言うに及ばない。が、大抵時間がなくなってしまって正常系のテストだけで終わってしまうことになる。 そうすると、もちろん異常系の処理になった途端、システムエラーを引き起こす。何をすべきか、それは予期している問題点を全て把握できるかどうかだ。 今回紹介するオープンソース・ソフトウェアはrcov、Ruby向けのソースカバレッジツールだ。 カバレッジツールとは、対象のプログラムソースが処理を一巡する中で通った場所と通っていない場所とを見極めてくれるソフトウェアだ。これを使えば通っていない場所は元々不要か、またはテストしていない場所かのどちらかに分けることができる。 結果はHTML形式でのレポートの他、標準出力でも可能だ。全体のコード量に対するカバレッジ率や、あるポイントを何回通ったかといったことも提示してくれる。 なお、公式サイトではRuby on Railsでも
The Apache Tomcat 5.5 Servlet/JSP Container - JNDI Datasource HOW-TO Please note that JNDI resource configuration has changed somewhat between Tomcat 5.0.x and Tomcat 5.5.x. ということで、JNDI使用時はバージョンに注意。 JDBCドライバのjarファイルは、TOMCATのcommon/lib/配下に置いておく RFP完全マニュアル 実践編 - RFP完全マニュアル 実践編(目次):ITpro Amazon.co.jp: RFP&提案書完全マニュアル Amazon.co.jp: RFP入門―はじめての提案依頼書 [指南役の提言]コスト削減を目的としたERP導入は成功しない:ITpro ” 業務プロセスの標準化は、業務の
This article was migrated from http://rails.office.drecom.jp/takiuchi/archive/158 馬場さんが書いてるやつをちょっと修正したもの。 1 desc 'Commit to the repository safely.' 2 task :commit => [ 3 :up, 4 :'db:migrate', 5 :test, 6 :'test:plugins', 7 ] do 8 if msg = ENV['M'] 9 msg.gsub!(/\"/, '\"') 10 system %Q{svn ci #{RAILS_ROOT} -m "#{msg}"} 11 else 12 system "svn ci #{RAILS_ROOT}" 13 end 14 end 15 16 des
I'm working on Edge Rails again doing some RESTful API stuff, so I'm watching the Rails commits fairly closely these days. Earlier today Tobi committed patch [6647] the long-awaited assert_difference and assert_no_difference test helpers. You can use them like so: def test_create_user login = "bob" name = "Bob Dobbs" assert_difference(User, :count, 1) do bob = User.create!(:login => login, :name =
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く