『るびま』は、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 直
5 years know-how of RSpec driven Rails app. development. 2011年07月17日(日) (大ホール) 概要 Ruby on Railsを使ったプロジェクトにおいて、RSpecでテストを書きながら開発を進めていくノウハウについてお話しします。 現在、Railsを使った開発プロジェクトでは「RSpecなどによるテスト駆動開発をしたほうがよい」という考え方が極めて一般的なものになっています。RailsやRSpecのツールとしての使い方を照会している、書籍や良質なWebサイトも数多く存在します。 それでも、テストしやすい設計や、メンテナンスしやすいテストの書き方などのノウハウには唯一の正解などがあるものではありません。RailsやRSpec自体やそれを取り巻くテスティングツールもどんどん変化していきますし、方法論も変わっていきます。 この講演
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 直
※2011/11/08 コメント欄で指摘を頂いた箇所を加筆修正しました。また、割と古い記事ですので最新の情報は Fabrication を参照することをお奨めします。 これを作ってるとき、machinistとmachinist_mongoを使っていたんですが、試しに前々から気になっていたFabricationで書き換えてみました。README書いてあることをいくつか実際にやってみたのでメモしておきます。割と使いやすかったです。 何に使えるの 下記をサポートしてるそうですので、Mongoid使えます。やった！ Plain old Ruby objects ActiveRecord objects Mongoid Documents 使ったもの Fabrication…本日のメイン Faker…嘘データをどんどこ作ってくれるやつ QuickStart & 使い方 Gemfile Rails/M
『るびま』は、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 直
『るびま』は、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 直
追記2（2015/09/08）ありがたいことに、未だにこの記事をブックマークしてくださる方がいらっしゃいますが、2008年に書いた記事なのでご注意下さい。内容はアップデートしていません。私自身はすでにRubyを使っていません。 追記：古い情報ですので、記事の日付とお使いのRSpecのバージョンを見比べて、参考程度にご覧ください。大部分は通用するはずですが。 Matcherをいちいち調べるのが面倒になって、公式のリファレンスマニュアルは一覧性が低いから、自分で一覧表を作った。 RSpecそのものについては、スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)などをどうぞ。そのうちRSpec on Rails版も作る予定。 名前 not((should_notで使えるかどうかという意味。)) 意味・機能 == ○ ==演算子を利用して比較する。ex
2009年07月01日01:07 Ruby RSpecでテストコードを書いたまとめ 最近は Ruby のテストに興味があっていろいろ試しています。 今気になっているのは RSpec と Cucumber の2つ。今回はまず RSpec を色々触ってみたのでそのときのログをメモってみます。RSpec については RSpec + Autotest::screen = 最高の開発環境 でも書きましたが、BDD（振舞駆動開発）のフレームワークで、describe と it という2つのメソッドを利用します。describe にテストしたい振舞を書き、it にはそのときに満たすべき仕様を書くという感じです。今回は Rails で RSpec を使ったテストを書いてみましたよ。(=ﾟωﾟ)ﾉ 事前準備として、rspec と rspec-rails と Zentest（テストを自動で走らせるため。この中
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
これは何? 会社で RSpec を使った、BDD を行っているのて理解の為にまとめてみました RSpecってんなんぞ?? 一言でいうと、BDD の為の DSL 日本語でおk DSL ドメイン固有言語 やりたい事に特化した言語 今回の場合は、BDD に特化した言語(実際には、gem を使った Ruby の拡張) BDD 振舞駆動開発(behavior driven development) プログラムの振舞(≒要求仕様)を先に書く開発手法 っていうと普通だけど、その振舞がテストコードにもなる そのための DSL が RSpec BDDの歴史 XPのテスト駆動開発(TDD) ↓ テストにより、逆に仕様が明確化 ↓ テストってある意味要求仕様と同一だよね ↓ 自然言語で書かれれば、いろいろ便利だよね ↓ DSLの開発(RSpec等) ↓ BDD BDDだと何が得? TDDより、テストコードが可読
vimから簡単にrubyのテストを実行出来るvim-rubytest ファイル単位 テストケース単位 に対応しているからうれしい かつ、 testunit rspec cucumber にも対応。テストファーストな開発のお友達です！ rspecで動かなかった rspecに対応していないわけではない。 自分の環境でrspecをたまたま動かせなかったのだと思う。 :!echo 'rspec spec/models/hoge_spec.rb' && rspec spec/models/hoge_spec.rb rspec spec/models/hoge_spec.rb zsh:1: command not found: rspec けどできないでいるのはいやなので、ちょっとだけいじる。 rspecじゃなくて、specならいるので、 vim-rubytest/plugin/rubytest.vi
以前 Ruby on Railsの達人 @a_matsuda に 薦められた テストツール Steak を現在開発中のプロジェクトで使ってみようと思い、勉強してみました。 Steakとは Steak は Cucumber 同様に Ruby on RailsなどのWebアプリの受け入れテストや総合テストのツールです。Cucumberは仕様(テスト)を自然言語で記述できるのが大きな特徴でしたが、SteakではRSpec＋専用DSLで記述しまます。 Cucumberは仕様(テスト)を自然言語で書けるので、ユーザーに仕様を確認してもらうとか作ってもらえるのが最大のメリットです。しかしその分、feature(仕様)とStep(仕様をプログラムをつなぐコード)の２つを記述する必要あり開発の手間が取られます。 それに比べ、 Steak は RSpec (＝ Rubyのコード) なので、プログラマーに取っ
開発中のシステムでは multi_db を使ってMaster/Slave型のRDB負荷分散を行っていますが、こういうアプリでRSpecを書くのは一筋縄ではいきません。 Master/Slave型のRDB負荷分散を行うシステムではRDBへのinsert/updateはMaster-DBにのみ行い、selectはSlave-DBに対して行います。 multi_db では、 ドキュメント にあるように、通常のアクセスはSlave-DBに対して行い、コントローラのアクションまたはモデル単位でMaster-DBにのみアクセスするように指定します。 このようなシステムのテストでmulti_db自体が本当にRDBアクセスをMaster-DB、Slave-DBに振り分けているかのテストは不要だと思いますが、アプリ内にMaster-DBにのみアクセスさせる為のコードを書いているので、アプリが本当にMaste
Rails3 でプロジェクトを作成し、RSpec と RCov を日本語で動作させるまでの手順です。 rails (3.0.0) や rspec (2.0.0.beta.22) 等の必要な gem は既にインストールされているものとします。 まずは、普通に Rails プロジェクトを作成して、config/database.yml を開発環境に合わせて設定しておきます。 $ rails new project create create README create Rakefile create config.ru create .gitignore create Gemfile ： ： プロジェクト内にて RSpec と RCov を使用するために Gemfile に下記を追記します。 gem "rcov" group :test do gem 'rspec-rails', '>= 2.
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く