実はCapybaraってよく分からないんです
というか、この辺の用語がいつも混乱してとても困っていたのでいったん整理。今回のターゲットは何やら最近 JavaScript を含む Web アプリのテストでよく名前を聞く capybara-webkit からスタート。 間違ってたら突っ込んでください！ 間違ってなかったら褒めてください！ 名前capybara-webkitCapybara の driver. Capybara のテストを WebKit を通じて実行できる。WebKit と言えばみんな大好き、Google Chrome や Safari のエンジンですね。capybaraテスティングフレームワークに対して Web アプリのテストを書きやすくする語彙を提供してくれる( DSL や Driver で実装されている )。driver は default で rack_test で、JavaScript を含む場合は Seleniu
テストフレームワークmochaとファイル監視watchrで自動テスト - mizchi log
npm install mocha -g npm install shouldmochaの--watchオプションが期待通り動けば問題ないんだけど、ホットリロード動いてないのでファイル監視はwatchrでやらせることにした。 guardでもよかったんだけど、guardは皆決まりきったサンプル動かしてる人達が多くて、独自な挙動をとらせようとするとRuby詳しくない自分にはwatchrの方が取り回しがよかった。 gem install rb_fsevent watchrrb_fseventはMacの場合。それ以外の環境だと別のモジュール(ぐぐれ)が必要 たぶんgrowlnotifyが必要 Growl - Downloads mochaに渡している項目はこんな感じ。 mocha -c --reporter list -r should --ignore-leaks --growl --compi
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
Watir Project
Watir is... An open source Ruby library for automating tests. Watir interacts with a browser the same way people do: clicking links, filling out forms and validating text. Get Started Now... require 'watir' browser = Watir::Browser.new browser.goto 'watir.com' browser.link(text: 'Guides').click puts browser.title # => 'Guides – Watir Project' browser.close Watir 7.3 Watir 7.3 is now available on R
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
外部サービス（アプリケーション、API）と連携するRailsアプリ開発
5. • HTTParty http://github.com/jnunemaker/httparty/ • DSL (Easy get, post requests) • JSON and XML 7. • Rails $ruby script/server : localhost:3000 • Sinatra ex.) RAILS_ROOT/lib/api_server/server.rb $ruby ./lib/api_server/server.rb : localhost:4567 8. • http://gist.github.com/122074 RAILS_ROOT/script api_server $ruby script/api_server • • CTR+C • ex.) ruby script/api_server -p 3001 Editor's Notes&
Rubyの開発者を「ヒーロー」にしたい、「Heroku」責任者が語る
以前インタビューをした米ヘロク（Heroku運営会社）のジェームス・リンデンバウム氏（前CEO）から、サービス名のHeroku（ヘロク）は、「Hero（ヒーロー）」と「Hike（俳句）」の合成語だと聞いたことがあります。 そうだ。Herokuのミッションは、Rubyを使う開発者を「ヒーロー」にすることだ。 開発者は偉大なアイデアを思いついたら、それをRubyのプログラムにして、Herokuのプラットフォーム上に展開すればいい。そうすればそのアイデアは、すぐに実現可能になり、開発者はヒーローになれる。 従来、アイデアをWebアプリケーションという形にするためには、サーバーを購入したり、設定したり、管理したりする必要があった。HerokuのようなPaaSを使えば、これらの労力は一切不要になる。 PaaSとしてのHerokuの強みは、どこにありますか？ Herokuを使う開発者は、三つのことに驚
連載：Ruby Freaks Lounge｜gihyo.jp … 技術評論社
第40回RVM（Ruby Version Manager）による環境構築（2） 三村益隆 2010-04-27
川o・-・）＜2nd life
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
Ruby Debuggerの良さ - 技術メモ帳
会社からだから、走り書き。 特に推敲もしていない。一度も見直していない。 だが、これは限りなく本音に近いのだ。 ruby -rdebug hoge.rb よく使うコマンド break クラス:メソッド名 delete ブレークポイント解除 c ブレークポイントまで続行 l 該当ソースコード表示 n 次の行へ s 次の行へ、関数であれば中に入る p 画面にデバッグ表示 catch off 例外発生時に止まらなくする。 catch <Exception> 指定した例外発生時に停止 var l ローカル変数をすべて表示 良いところ rubyの標準モジュールが使えるところ。 irb 見たいな感覚で使える。 当然、デバッグ中に require 出来るので、 たとえば、pritty print したかったら require 'pp' pp @hoge とかもできるし、 require 'y' y @h
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - porras/mrproper: Property Based Testing in Ruby
噂のRuby&Githubなプロジェクトにスキな継続的インテグレーションサービス「Travis CI」を試してみたらすごくよかった