Inouetakuya
Chefのテストスイーツを色々試してみた （1）chefspec, minitestなどによるテスト整備 - カイワレの大冒険 Third
エンジニアのみなさま、自動化は進めていますでしょうか。海外ドラマにハマってる@masudaKです。 すたじおなんとかさんが、以下のようなことを仰ってまして、 . @kenjiskywalker さんとか @nakashii_ さんとか@mikeda さんとか@masudaK さんとかはユーザローカルなRuby環境作るcookbookとか既に書いてそう— Satoshi.S (@studio3104) 2013, 3月 13 rbenvのcookbookでも作ろうかなと思ったのですが、折角なので前から触りたかったツールを色々使ってみました。その紹介記事であります。 記事書こうかなと思ってるうちにVagrantがクリティカルに進化してたりして追いつけてない（近いうちに動かなくなる）部分もあるかもしれませんし、Rubyも触りしかわかってないので、間違い等あったらご指摘お願いします。 ちなみにCh
Evergreen で Rails アプリの JavaScript を単体テストする - present
はじめに Rails アプリの JavaScript のテストは capybara(+capybara-webkit) を使えば一応できるけど、統合テストなのがね…。統合テストもちゃんと書くけど、やりたいのは JavaScript の単体テストなのに。 そこで Evergreen そんな中で最近知ったのが Evergreen っていう gem。 jnicklas/evergreen · GitHub こいつを簡単に説明すると、Rails に組み込める Jasmine テストランナー。Jasmine も同梱されてるので、インストールすればすぐに JavaScript のテストが書ける。 Evergreen のインストール Gemfile に group :test, :development do gem "evergreen", :require => "evergreen/rails"
DRY原則とテストの可読性 - ✘╹◡╹✘
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
私はRSpecでテストをこんな感じで書いてる - アジャイルSEを目指すブログ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
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 の挙動
あなたが理解できない，たった一行のRubyのコード （動的言語に対する静的解析の限界） - 主に言語とシステム開発に関して
あなたは，下記のコードを理解できない。 p f /g+h/i これはRubyのコードである。「p」は，コンソールに出力する関数である。 問： だいたい，何をやっているコードですか？ ※例えば，四則演算など。 構文をおおまかに説明して下さい。 どれが変数で，どれが関数で，どれが演算子か？ ↓回答 回答： 一意に決定できない。 下記に， このコードの複数の解釈方法と， この件が引き起こす問題 について述べる。 ※なお，この問題が起きるのは動的言語に限らず，静的言語でも同様に発生しうることを前もって述べておく。 （１）分数の計算とみなすパターン 先行するコードを下記のように書いた場合： test1.rb # 変数に数値を代入 f = 2 g = 1 h = 2 i = 1 # 演算結果をpで出力する p f /g+h/i 実行結果： >ruby test1.rb 4 「分数の計算」とみなされる。
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
いまどきの Ruby 書くときのテスト環境 - Stats of the Rivers
romaji というライブラリを書いた。 - 寿司じゃないブログ という記事を書いたのだが、テスト環境について反応があったのでもうちょい詳しく書く。 RSpec テスティングツールのデファクトスタンダード。 http://rspec.info/ に行くか、The RSpec Book を読もう。 Guard ソースコードが編集されているかを監視して、変更があった場合に自動でテストを走らせてくれる。 guard/guard · GitHub guard と guard-rspec を gem install して、以下のようなファイルを Guardfile という名前でプロジェクトのルートディレクトリに置き、 guard コマンドを走らせると、watch で指定したファイルの変更の監視してくれる。 guard 'rspec', :version => 2, :all_after_pass =
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記
Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
地獄Spec
