Add new features to your browser and personalize your browsing experience.
VirtualBox 4.2.14 + Vagrant 1.2.2 の組み合わせで、正常に動作しなかった問題が、VirtualBox 4.2.16 で解決されたようです。 VirtualBox 4.2.14 + Vagrant 1.2.2 の組み合わせで、一部の環境にて vagrant up ができないという現象がありました。 $ vagrant up Bringing machine 'default' up with 'virtualbox' provider... [default] Importing base box 'precise32'... There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and std
昨日 http://d.hatena.ne.jp/naoya/20130620/1371729625 で書いたように Docker を使えば、欲しい VM を "任意の状態" で簡単にかつ" "瞬時に" コピーして作り出すことができる。 「任意の状態」というのは、例えば「OS は CentOS で、Ruby と Chef が入っている」みたいな VM のこと 「瞬時に」というのは本当に瞬時。VM の起動時間を待ったり、Ruby や Chef を入れる時間を待つ必要はない serverspec でテストをする場合、真っ新な VM を用意してそれにプロビジョニングを行って、その後に破棄するみたいなことを良くする。このとき「真っ新なVM」を立ち上げるのに、Vagrant などが使えるが、Vagrant だとテストの度に VM を一から作り直す・・・つまり vagrant up しなければいけない
Docker をいじって遊んでいる。 http://www.docker.io/ Docker は PaaS ベンダの DotCloud がその PaaS のバックエンドとして使っている (?) ミドルウェアを公開したもの。適当な条件の VM をポコポコ生み出してはテストや実際の運用に使うことができたりするもの。例えば「Ruby と Bundler が入っている VM」みたいなのを設定で作っておくと、後日何か Ruby でアプリケーションを動かしたいと思ったときにそのイメージをベースに VM を作ってデプロイしてやればすぐにアプリケーションが動き出す。そもそも PaaS がやっているのはそういう事で、それを汎用化したのが Docker。Travis CI のような、各言語ごとの実行環境が整った VM みたいなものに任意のコードを渡してビルドさせる、みたいなプラットフォームを作るのにも使える
先日 モックとスタブ - 日々此妄想 の悩み File.foreachみたいなブロック付きメソッドのスタブってどうやって書くのかなぁ。。。。 Young risk taker.: [RSpec] Mock API を見ていて、たぶん and_yield だというところまでは目をつけていた。 yield わかってるつもりだったけど、ちょっと甘かったっぽい。 def foo yield(1,2) end foo {|a,b| p [a, b] } # => [1, 2] (要するに p [1, 2] を実行した) これは理解できてたんですよ。はい。 じゃー Array#each みたいなのはどうするのか理解できてなかったっぽい。*1 で、and_yieldを知るには、まずyieldだと思ってRubyのリファレンスを見ました。すると目から def bar yield 10 yield 20 yi
Mock Object Mock Objectの作成 my_mock = mock(<name>) my_mock = mock(<name>, <options>) person = mock('person', :null_object => true) Mockは名前を引数に取る。仕様の検証が終わった際に全てのMockが検証される。 option引数をハッシュで与えることでMockの振る舞いを調整できる。現在、:null_objectのみがサポートされている。:null_object => trueを引数に渡すとMockに対する全てのメソッドがMock自身を返すようになる。 Mockに対してスタブメソッドを定義する person.should_receive(:name) # person.name => nil person.should_not_receive(:name) #
まとめ sidekiqを2つのRailsアプリケーションで使ってみて、テストの書き方と残し方について思うところがあったので書いてみます。 特別な事情がなければsidekiq/testingを使うべき(sidekiq/testing/inlineは使わない) 非同期処理そのもののユニットテストはMyWorker.new.performで書けばよい 非同期処理をキックする側のユニットテストはMyWorker.jobs.sizeを検証するだけにする エンドツーエンドテストでは「全ての非同期ジョブを実行する」というようなstepやメソッドを作ってそれを呼ぶ sidekiq/testingとsidekiq/testing/inlineについて sidekiqのwikiには、テストのための仕組みとしてsidekiq/testingとsidekiq/testing/inlineの2つがあり、**「どちら
先日告知した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
追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou
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,
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
以下の文章はŽ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のことだ。読
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く