🖥 VULTRおすすめ 「VULTR」はVPSサーバのサービスです。日本にリージョンがあり、最安は512MBで2.5ドル/月($0.004/時間)で借りることができます。4GBメモリでも月20ドルです。 最近はVULTRのヘビーユーザーになので、「ここ」から会員登録してもらえるとサービス開発が捗ります!
![RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
こんにちは、ほりいです。Asset Pipeline に感銘を受けている今日この頃です。 今日は社内で RSpec をこれから勉強したいんだけど検索してもよくわからない!と質問を受けたので、読むべきエントリをまとめてみました。 # 現状ぐぐると RSpec.info がまず出てくるけどもう更新されてないっぽいので優しくないんですよね…… h2. これは読んでおこう! h3. スはスペックのス * “スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)”:http://jp.rubyist.net/magazine/?0021-Rspec * “スはスペックのス 【第 2 回】 RSpec on Rails (コントローラとビュー編)”:http://jp.rubyist.net/magazine/?0023-Rspec 内容は若干古いのですが、
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
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 の挙動
38. ⑤失敗・教訓(充実してきた頃) カバレッジは万能じゃない -「レガシーコード=テストの無いコード」なので意 味はあるが・・・ -Reekを取るようにした(お手軽/ReekViewer) https://github.com/Shinya131/reekviewer FactoryGirlがパンクした -factory.rbに全てぶっ込むのではなく、 factoriesフォルダ以下にファイル分割配置 -リレーション指定やりすぎると破綻(メンテ不能)に
こんにちは、SHIMADAです。 今日は現場の泥臭いRSpec話を書きます。 新しいフィーチャーを追加するとき、specがなかなか通らない、実装が思い通りに進まない、ということがありますよね。 そんなとき、自分の書いたコードが実際にはどう動いているのか確かめる方法が欲しいです。 一番簡単で広く使われているのはデバッグプリントという手法です。 コードの中に p 変数名 と書くと、specの実行途中にその変数の中身がどうなっているか確認できます。 ここで問題になるのが、specがたくさん書いてあるとデバッグプリントが一杯出てきて肝心の調べたいケースが埋もれてしまうという点です。 ちなみに今携わっているプロジェクトのspecを見てみると、examplesの数が1,000を超えてました。 これが一般的な水準で多いのか少ないのか分かりませんが、ここまできてしまうとデバッグプリントがどかどかっと表
めもめも。 この記事はRubyもRailsもよくわかっていない人が自分のためのメモとしてだらだら書きました。リファレンスがよくわからなかったので、動かして試してみた感じです。 RSpecは(Railsに限らず)Rubyで動くテストフレームワーク。Railsに最初から入ってるTest::Unitよりも色々と良いらしい……けどそっちも使った事がないので比較はできません。 RubyじゃなくてRailsから利用する視点から俺用にまとめます。 環境 $ ruby -v ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux] $ rails -v Rails 3.2.1
『るびま』は、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 直
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
『るびま』は、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 の書き方について 要約:RSpec は単なるテストを英語っぽく書けるツールではなく開発の全プロセスを加速するツールであるのでプロジェクト初期から有効に利用する必要がある。 4/1 ですが気にせず真面目な話を書きます。 RSpec は多分 Ruby 界隈で一番使われているテストフレームワークの一つだと思います。であるので使い方の解説や概念の解説多いですが、個人的にはそれらの解説は的を外したものが多いと考えています。 RSpec の真髄を会得するには、 RSpec の spec をどのように書くかということを考えてゆく必要があると思います。 まず RSpec の特徴的な点とはなんでしょうか。 RSpec でテストは以下のように書かれます。 describe "肛門" do context "排便する時" do it "高速に排便されると肛門がすりきれる" do 肛門がすりきれるとい
I watch a lot of tests run in a given day. So I figured why not make it more fun. Inspired by minitest’s pride, and um cats? I came up with a Nyan Cat inspired RSpec formatter. Update: After last week’s launch, Nyan Cat received a great response from the Ruby world. Over the weekend, I released version 0.0.2. It includes a few bug fixes and some really cool enhancements. Most notably, Nyan Cat now
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く