Better Specs { rspec guidelines with ruby }
translations Documentation RSpecとはBDDで使う素晴らしいツールです。(BDDとはbehavior-driven developmentの略で方向性を人の読める仕様に沿って開発を行う開発方法論です。) ウェブで既に沢山の使い方や _何_ ができるかを説明したRSpecの書き込みを探せますが、RSpecで良いテストの作り方を説明した書き込みはなかなか探せません。 Better Specsは大抵のガイドラインの書いてない部分を集めようとしました。- これは開発者達の経験を通して学んだ方法です。 メソッドの説明をする 作成中のメソッドを明らかにしましょう。例えば、Ruby文書の規約ではクラスメソッドの名前には.(もしくは::)をインスタンスメソッドの名前には#を使っています。 bad
RSpec 3の重要な変更 - 有頂天Ruby
Myron Marston » Notable Changes in RSpec 3の雑な訳です。 誤訳・雑すぎる訳がありましたら、Twitterで@nilp_までご連絡頂けると助かります。 RSpec 3.0.0 RC1が2日前にリリースされました、そして最終的な3.0.0のリリースが目前に迫っています。 我々はβ版をここ6ヶ月にわたり使ってきました、我々はそれらを皆さんと共有できることにわくわくしています。 これが新しいとこだよ: すべてのgemたちにわたって Ruby 1.8.6と1.9.1のサポートがなくなりました これらのバージョンのRubyはかなり前に寿命を迎えました、RSpecはこれらをサポートしません。 Ruby 2.xのサポート向上 最近のRSpec 2.xのリリース(すなわち2.0がリリースされたあと出たやつ)はRuby 2を公式にサポートしています、しかしRSpec
私はRSpecでテストをこんな感じで書いてる - アジャイルSEを目指すブログ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
地獄Spec
38. ⑤失敗・教訓（充実してきた頃） カバレッジは万能じゃない -「レガシーコード=テストの無いコード」なので意 味はあるが・・・ -Reekを取るようにした（お手軽/ReekViewer） https://github.com/Shinya131/reekviewer FactoryGirlがパンクした -factory.rbに全てぶっ込むのではなく、 factoriesフォルダ以下にファイル分割配置 -リレーション指定やりすぎると破綻（メンテ不能）に
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
るびま
『るびま』は、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 直
RSpecとtest-unit 2での抽象化したテストの書き方の違い - 2011-07-12 - ククログ
日本Ruby会議2011の3日目の「テスティングフレームワークの作り方」の準備をしていますが、30分だと詰め込み過ぎになってしまうので、話さないことを事前に書いておきます。それは、テストを抽象化するためのAPIの違いです。 RSpecとtest-unit 2でのAPIの違いというと、class UserTest < Test::Unit::TestCaseとdescribe Userやassertとshouldの違いの方が目に付きますが、抽象化するためのAPIにもツールの特徴が出ています。抽象化するためのAPIはテストの量が増えてくると必要になる大事な機能です。ここでは、その中でも「テストを共有するAPI」について考えます。 まず、ツールの考え方について確認し、その後、それぞれのツールでどのようなAPIになっているかをみます。 ツールの考え方 まず、それぞれのツールの考え方について確認しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明
RSpec functions