先日告知したCandyCaneの開発会が無事に執り行われました。参加者の皆様にはCandyCaneの特製パーカーと肉たくさんカレーを進呈させていただきました。Hamacoさんの動きっぷりにイベントの盛況さが現れています。 丸一日のTDDは強烈な成果 今回は新しく開発に加わってもらう方を募るという事も兼ねて、ユニットテストを厚くするという作業を中心に丸一日の開発を行いました。よって1日で20以上のプルリクエストをマージしましたが、昨日は何も増えていません。とはいえ実際に稼働するアプリケーションのソースコードにテストを書き、プリリクエストとCIを併用したチーム開発を行うという内容は実にチャレンジでTDD未経験の方にとっても実りある内容になったようです。 Travis CIは最強 コミットがプッシュされる度に自動的にユニットテストを実行して結果をレポートしてくれるTravis CIですがやはり便
Cucumberって、仕様設計者の意図をプログラムによる自動テストにできる魔法です。 仕様設計者っていうのは、Rubyでのプログラミングが難しいけど、お客さまのニーズを理解して、それをドキュメントにできるハイパーな人です。プログラマにとっては神様です。 (でも、それがプログラマの徹夜の源なのだったりしますよね。実現が困難で意図が不明な仕様を必死で実装する感じですよね。だから、それをなんとかしなければ徹夜は解消できないと考えてみました。) Cucumberではプログラマ以外の人でも分かりやすい記述ができます。 でもね、どうせそのドキュメントを見るのはプログラマだけです。なので、生のCapybara APIで十分なのかもしれませんね。なので、ここではRSpecのfeature specを考察します。 from Feature spec on Relick : https://www.relis
I would try mapping $stdout and $stdin to some temp variables, assigning a File object to $stdout and $stdin and then restoring originals: original_stdout, original_stdin = $stdout, $stdin $stdout, $stdin = File.new('stdout.log', 'w+'), File.new('stdin.log', 'w+') ... #Do operations with my class ... #Restore original stdout and stdin and close opened files $stdout.close ; $stdin.close $stdout, $s
最近毎日のように読んでいるwycatsさんが便利なメソッドを利用していたのでメモしておく。 # -*- coding:utf-8 -*- require "rubygems" require "spec" # this method is written by wycats def capture(stream) begin stream = stream.to_s eval "$#{stream} = StringIO.new" yield result = eval("$#{stream}").string ensure eval("$#{stream} = #{stream.upcase}") end result end describe "Object#capture" do it do capture(:stdout) { print "hoge" }.should == "h
伴う、というかそれがメインの機能だったりもするわけですが。 少し前、以下の記事でごく単純な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
Sinatra is a fantastic lightweight framework for building web services. We’ll use it as the application framework for the HTTP endpoints in our Service Oriented Architecture. The testing approach will be in-process, which means that the test suite is running in the same Ruby process as the web service. This eliminates the need to run an external HTTP web server. Application structure Unlike Rails,
以下の文章はŽeljko Filipinによる"Watir in five minutes"の翻訳です。*1 (中略) 僕が初めてWatirを仕事で使った時、すごく驚いたことを今でも覚えている。インストールしてから数時間で、僕はテスト中のWebアプリケーション用のスクリプトを書けるようになっていた。この本を読めば、数時間もかからずにWebサイトをテストできるようになるはずだ。 もしRubyに親しんでいるのなら、IRBがRubyライブラリを勉強するための最良のツールの1つだってことがわかっているだろう。 もしRubyを知らないのなら、こう思うかもしれない。IRBって何? IRB(この場合)はInternational Ruby BoardでもImmigration or Refugee Board (of Canada)のことでもない。Interactive Ruby Sehllのことだ。読
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、PHP、Node.jsの環境をクラウド上でPaaSとして提供しているEngine Yardは、クラウドと互換性のある環境をローカルで構築できるソフトウェア「Engine Yard Local」を、Engine Yardが無償で公開しました。 Engine Yard Localを利用することで手元のコンピュータだけで開発環境が完結するようになるため、クラウドへ接続することなくアプリケーションの開発が行え、クラウドにかかるコストを削減できます。開発者も、どんな場所でもアプリケーションの開発が可能になりますし、生産性の向上もはかれるでしょう。本番環境へデプロイするChefのレシピをテストすることも可能。 仮想マシンをツールから制御する仕組み Engine Yard Localは、オラクルのVirtualBoxを、Rubyで作られたオープンソースのツールVagrantを用いて制御し、仮想
A NEW LOOK AT TEST-DRIVEN DEVELOPMENT Dave Astels dastels@daveastels.com A S T E L S C O N S U L T I N G 19 Ran d St ., H an t sp or t , N ova Scot i a, Can ada B0P 1P 0 • ce l l : 902.691.2334 • f ax : 902.684.0923 • www.dave ast e l s.com The Problem Test Driven Development (TDD) has made it to prime time. Big companies are paying big money to have their programmers trained in how to do TDD. It
The state of Test Driven Development For the latest version of this information go here and get the article that grew out of this post Test Driven Development (TDD) has made it to prime time. Big companies are paying big money to have their programmers trained in how to do TDD. It’s a popular topic at conferences… agile and otherwise. My book on TDD won a Jolt award. So everything’s rosy, huh? Eve
257: request specとCapybara (view original Railscast) Other translations: Other formats: Written by Naomi Fujimoto ハイレベルテストは、Railsアプリケーションをテストする優れた方法です。この種のテストでよく用いられるCucumberについて、エピソード155[動画を見る, 読む]で取り上げました。Cucumberの、アプリケーションの振る舞いを英語の文法で定義するやり方が好きではない人もいるでしょう。そこで今回はハイレベルテストを実行する別の方法を見てみます。 普段はテスト駆動開発を奨励していますが、今回はすでに完成したアプリケーションにテストを追加することにします。それによって、実装の詳細やアプリケーションが正常動作するかどうかに気をとられることがなくなります。これから
あんまり需要なさそうなのでメインブログから引っ越し。mockについて。 14.1 Test Doubles Test Doubleは他のオブジェクトの代わりをするオブジェクト Spec::Mocks double("double") stub("stub") mock("mock") これらのメソッドは全部同じで Spec::Mocks::Mock クラスのインスタンスを作成する。引数の文字列は option 扱いだけれど、 failure message の中で使われるので入れておいた方がいい。 14.2 Method Stubs Method Stub はあらかじめ決めておいたresponseを返すメソッドのこと。 describe Statement do it "uses the customer's name in the header" do customer = double
What I’ve found A few minutes ago, I was watching a great screencast of Corey Haines doing a kata. I stopped when he was refactoring a few similar assigments. There was something I’ve never seen elsewhere, particularly in the also great RSpec book ; he used the let() method. Going back and forth a few times, I understood the the method was assigning the result of the given block to an object named
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く