_ko1 @_ko1 やっぱり spec の書き方がわからない、のは理解が足りていないからだと思うんだが、書籍でも読むといいんだろか 2014-04-17 15:24:18
!["rspec の書き方がわからない"](https://cdn-ak-scissors.b.st-hatena.com/image/square/3dd8a16a686ccc2289c21a64075f3b5b3b8c83bf/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fs.tgstc.com%2Fogp3%2Fcfacdd96f6fdfa3c501e01d04f84b036-1200x630.jpeg)
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
RSpec ships with a number of useful Expression Matchers. An Expression Matcher is any object that responds to the following methods: matches?(actual) failure_message_for_should These methods are also part of the matcher protocol, but are optional: does_not_match?(actual) failure_message_for_should_not description #optional These methods are from older versions of the protocol. They are still suppo
すでに前回のすごいぞRSpec(shared example group編) - ぷろぐらまねがで登場してるけどあらためてletを調べるよ。rspec-core(2.5.1)/features/helper_methods/let.featureを参考に。 let 要するにメモ化するわけで、同一サンプル内だと同じオブジェクトを使いまわせるのだな。違うサンプルでは改めて評価される。さらに遅延評価なので実際に評価されるのは最初にメソッドが呼ばれたときだ。 $count = 0 describe 'let' do let(:count) { $count += 1 } it 'memoizes the value' do count.should == 1 count.should == 1 end it 'is not cached across examples' do count.shou
ちょっと前に話題になったRSpecのスライドがステキだったよね。でもRSpecはまだまだ底知れない気がするので自分でもいろいろと調べてみようと思った次第。 まずはrspec-core(2.5.1)/features/example_groups/shared_example_group.featureを参考にshared example groupについて調べてみたよ。 例1:テストを共有できる require "set" shared_examples_for 'a collection' do subject { described_class.new [7, 2, 4] } its(:size) { should eq 3 } it { should include 7 } it { should_not include 9 } end describe Array do it_be
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く