Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Ruby on Rails Tutorialのエッセンスを自分なりに整理してみる7 Railsにおけるリンクの記述方法とそのテスト http://qiita.com/kidachi_/items/d704e7eb63513c3831ae の続き。 Ruby on Rails Tutorial(chapter5) http://railstutorial.jp/chapters/filling-in-the-layout#sec-layout_exercises Rspecのリファクタリング 指定のページが指定の要素を持っている(もしくはいない)かをチェックするテストコード。 require 'spec_helper' describe "Static pages" do describe "Home page" do it "should have the h1 'Sample App'"
<この記事は「Money Forward Advent Calendar 2015」の12日目の記事です> Railsでアプリを書いたり、RubyでRailsを書いたり(主にBug Fix)しています。金子です。 前書き RailsのCIではRailsのmasterとRubyのtrunkでテストが回っています。普段、趣味でこのテストを眺めていて、テストが壊れたりすると原因を調べてFixしたりしています。 RubyにもRailsにも毎日新しい機能が入っていますので、それらが衝突して思わぬバグが生まれることもあります。今年見ていて面白かったバグを3つほど紹介したいと思います。 第3位 突然の大量Error 例えばテスト結果はこちら。 1) Error: BelongsToAssociationsTest#test_with_select: ArgumentError: wrong number
assert assert_block assert_equal assert_no_match assert_not_equal assert_not_nil assert_not_same assert_not_send assert_nothing_raised assert_nothing_thrown assert_raise assert_raise_with_message assert_respond_to assert_send assert_throw assert(test, [failure_message]) assert_block( failure_message = nil ) assert_equal( expected, actual, failure_message = nil ) assert_no_match( regexp, string, fa
ちょっとややこしいタイトルだけど、つまり 単体テスト (機能テスト): 正しくリダイレクトされるか 正しいステータスコードか (Temporary? Permanent? See Other?) 正しいリダイレクト先か 受け入れテスト: リダイレクトを透過して正しい動作をしているか GET /posts/1/edit -> PUT /posts/1 -> GET /posts/1 みたいなリダイレクトが透過的に行われることがある GET editで入力された値がPUTで更新されたか? RSpecの Kernel.#describe でテスト対象、つまり単体機能か操作フローか、を切り分ける。 follow_redirect! を明示的に呼ぶことでリダイレクトを追うことができるので、それの有無によってテスト対象を切り替えることができる。 describe "PostController" do
この middleware ちゃんと動いてるか確認したい、とか、この middleware とこの middleware を同時に使うとなんかヘッダがおかしいけどどうなってるの!とか、そういうののデバッグ法。 単にログ吐く middleware を stack の途中に積めばよい。 @app.call の前後でそれぞれロギングできる。 class M def initialize(app) @app = app end def call(env) warn '='*80 env.each do |k,v| warn "#{k}=#{v}" end warn '='*80 triplet = @app.call(env) warn triplet.inspect triplet end end config.middleware.insert_before Rack::ETag, M con
はじめに 3月頃,『【Rails】RSpecでWeb APIのテストでハマったところ①』という初心者丸出しな記事を書きました. あれから9ヶ月ほど,お仕事としてRailsに触れたりしたため知見・スキルも向上してきたと思います. そして今,前述の記事を見直したところ恥ずかしくて顔を覆いたくなる感じになったので改めてWeb APIのテストについて書いていきます. APIのテスト? そもそもWeb APIのテストはどこに書くの?ってところからですが… Controller SpecではなくRequest Specに書いていきます. Use RSpec Request Specs Since we’ve established that we’ll be using Rack::Test to drive the tests, RSpec request specs make the most s
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 (構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw) しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな-」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫!!」なR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く