Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
先日行われたRails Developers Meetup 2019で、Clean Test Code Revisedというタイトルで発表しました。スライドはこちら。 動画も上がっているようなので興味のある方はどうぞ*1。 所感 ご存知のかたもいると思いますが、この発表は2017年5月に行われたRails Developers Meetup第一回目で発表した内容を更に一歩進めたものとなっています。 Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記 当時僕の頭の中にあった「こういうケースのときはこう書く。なぜならこうだから」というものを点で出したのが前回の発表で、それらを「脳に負荷をかけない」という線でつなげてまとめたのが今回の発表になります。 テストコードをレビューしたときに「これなんか読みづらいな…」と思って
Railsのテストで複数のオブジェクトの作成を簡易に行えるFactoryGirl。 FactoryGirlについて基本的なことを知っていることを前提に、RailsでFactoryGirlを使うよく使う機能やTipsをまとめました。 動作確認 Rails 4.1.7 Factory Girl 4.4.0 Factory Girl Rails 4.4.1 目次 1. Factory Girlのインストール 2. FactoryGirlシンタックスの省略 3. FactoryGirlの使い方あれこれ 3.1. オブジェクトのビルド、作成、スタブ作成、属性取得 3.2. 特定の値を指定してオブジェクトを作成 3.3. ブロックを渡すことで細かな処理を記載可能 3.4. 一度に複数のレコードを作成する 4. Factory定義のあれこれ 4.1. 他の属性に依存する属性を定義する 4.2. fact
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
新規アプリケーションの構成 Rack::VCR リクエストの記録 リクエストのモック リクエストの再生 おまけ: Androidアプリのテスト 弊社での利用例 未来 こんにちは、会員事業部の小室 (id:hogelog) です。気づけば弊社に入社してから2年と2ヶ月が経っていました。 今回はその2年2ヶ月で初めて会社プロダクトを rails new したRailsアプリケーションと、そのアプリケーションで利用したRack::VCR (https://github.com/miyagawa/rack-vcr) について簡単に解説します。 新規アプリケーションの構成 今回私が新規に作成したRailsアプリケーションは仮にここではomoikane(仮)と呼ぶことにします。omoikaneはリクエストがあると社内の汎用APIサーバにアクセスし、APIサーバから取得した情報を元にレスポンスを返すアプ
Photo by Gonzalo Baeza | Flickr - Photo Sharing! RailsでJSONを返すAPIを作成し、また、APIのテスト方法も説明します。 JSONを返すAPIは、RailsのActiveSupportより拡張されたto_jsonメソッドとDMMが開発したjbuilderというGemを使います。 APIのテストにはおなじみのRSpec3を使います。 動作確認 Rails 4.1.7 jbuilder 2.2.6 rspec-rails 3.1.0 factory_girl 4.5.0 目次 1. 前提条件 2. APIの作成 2.1. 1つのコントローラーでHTMLやJSONを返すAPI 2.2. JSONのみを返すAPI 2.3. APIのバージョニング 3. APIのテスト 3.1. テストファイルの準備 3.2. 一覧(index)APIのテス
前回のEbisu.rb#7に引き続き、 Ebisu.rb#8も参加しました。 勉強会の形式は前回同様で飲みながらRuby関連ネタを語り合う感じでした。 前回は19:30集合でしたが前回のKPTから20:00から開始でした。 今回は事前に仕込んだLTネタが3件あり話題が豊富でしたね。 当日の雰囲気はハッシュタグ#ebisurbの 4/25の参加者のつぶやき見てもらえればイメージ湧くかと。 後半ひと通りLT的な発表が終わってからお酒も進んでの雑談の中でRailsでのテストをどんな感じで書いてるか? という話題になりました。個人的に今回LTネタ的な感じで発表してみようかなと思っていて結局できなかったので 考えを整理する為にも書き残しておこうと思います。 結論から言うと私が関わるプロジェクトの場合はpoltergeist+turnip+Capybara+FactoryGirlで受入テストを、 Rs
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100%カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。(※) ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
spring は最近流行ってるので、既に知ってる方もいると思いますが Rails のプリローダーです。 Rails を使ってる人だったら bundle exec rails console とか bundle exec rails generate model user とか bundle exec rake routes とか、便利コマンドにお世話になることも多いと思います。 でも Rails ってとても巨大なフレームワークなので、コマンド一つ起動するにも Rails の資産が全部ロードされて結構な時間がかかります。なので Rails をあらかじめバックグラウンドで起動しておくことによって、コマンドの起動時間を大幅に短縮してくれるのが spring です。 前は Gemfile には書かずにシステムに gem コマンドでインストールして spring rake routes とかやってて
Test::Unitにおけるflunkと同じようなもの。 it のブロック内に内に書くとそのテストケース(Example)は必ず失敗する。 it "昨日布団の中で思いついた仕様" do violated end さっさとテスト書けよというプレッシャーが漂う。 テスト自体や実コードの実装の保留状態を示す。 it のブロック内にpendingと書くと、その行以降の処理は実行されない。 pendingメソッドを使うときには引数に必ず理由を書かなくてはならない。 it "一昨日風呂の中で思いついた仕様" do pending("やんごとなき理由") # 検証されないエクスペクテーション end またpendingにはブロックを与えることができ、その場合はそのブロック内の処理だけがペンディング扱いになる。 it "こないだバイクに乗ってて思いついた仕様" do pending("大人の事情") do
Editor's Notes\n\n\n\n\n\nテスト時間は早ければ早いにこしたことはない。全部のテスト通すの&a
http://www.youtube.com/watch?v=bNn6M2vqxHE 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 「Airbnbのテスト:巻き込み力のある人がポジティブな変化をもたらす」でLou Kosakが、依存関係のないユニットテストを実現するのに参考にしたというCorey HainesのGoGaRuCo 2011での講演です。 一番読込みに時間のかかる3rd partyエンジン = Railsとの関係を切り離す。 1 class ShoppingCart < ActiveRecord::Base 2 has_many :shopping_cart_products, dependent: :destroy 3 has_many :products, :through => :
Editor's Notes\n\n&#x4ECA;&#x65E5;&#x307C;&#x304F;&#x304C;&#x304A;&#x8A71;&#x3059;&#x308B;&#x30C6;&#x30FC;&#x30DE;&#x306A;&#x3093;&#x3067;&#x3059;&#x304C;&#x3001;\n\n&#x666E;&#x6BB5;&#x306F; Ruby &#x3068; JavaScript &#x3092;&#x4F7F;&#x3063;&#x3066;&#x304A;&#x4ED5;&#x4E8B;&#x3092;
はじめに 以前から何度か紹介しているRSpec本の翻訳が終了し、ついに販売を開始しました! 提供フォーマットはMOBI(Kindle)、EPUB(iBooks)、PDFで、下記のページから購入できます。 Everyday Rails - RSpecによるRailsテスト入門 - Leanpub 今回は改めてこの本の紹介を書いてみようと思います。 「Everyday Rails - RSpecによるRailsテスト入門」ってどんな本? 「Everyday Rails - RSpecによるRailsテスト入門 ~テスト駆動開発の習得に向けた実践的アプローチ~」はタイトルの通り、RSpecを使ったRailsの自動テストを説明した技術書です。 内容としては比較的易しめで、そこまで高度な話題は出てきません。なのでRSpecの未経験者~中級者かつ、Railsを使って開発している技術者がターゲット層にな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く