Rails 5.1とRSpec 3.6に対応した「Everyday Rails - RSpecによるRailsテスト入門」をリリースしました - give IT a try
お待たせしました！ ついに「Everyday Rails - RSpecによるRailsテスト入門」（以下Everyday Rails）の改訂版をリリースしました。 すでに日本語版Everyday Railsを購入されている方は、Leanpubのサイトにログインして最新版の電子書籍ファイルを無料でダウンロードすることができます。 このエントリでは今回アップデートされたEveryday Railsの内容を紹介します。 また、価格改定の予告も含まれているので、まだ購入されていない方はそちらもご一読ください。 改訂版の3大変更点 変更点その1：Rails 5.1 + RSpec 3.6に対応 2018.3.12追記：ブログ記事を翻訳しました！ 変更点その2：サンプルアプリケーションの変更 参考：サンプルアプリケーションのソースコード 変更点その3：本文の大規模なリライト アップデート手順 さらに
rspec-rails 3.7の新機能！System Specを使ってみた - Qiita
はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1 Rails 5.1.4 Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4 Chrome 62 ChromeDriver 2.33 サンプルコード この記事で使用したコー
読みやすいRSpecを書くためのTips - 弥生開発者ブログ
こんにちは、黒曜(@kokuyouwind)です。 最近見つけた面白いポケストップは「シーサーに似た守り神(メイドインタイランド)」です。 PokemonGOは飽きてきて、代わりに最新作のサン・ムーンが欲しくなってきました。 アローラロコンかわいいよアローラロコン。あとミミッキュ。 さて、Misocaに入社して一年弱が経ち、RSpecの書き方にも大分慣れてきたのですが、油断すると冗長で複雑なSpecを書いてしまいがちです。 既存のSpecが複雑だと新しいexampleを追加するときにも書きづらくなってしまうため、気づいたらなるべくリファクタリングするように心がけています。 今回は、最近自分が「こういう書き方だと読みやすく保守もしやすいのではないか」と思っているRSpecの書き方について紹介していきたいと思います。 Specを記述する対象と文脈に着目して分割する 最近書くSpecでは、大体
RSpecの指針について網羅的に書いてみたかった - Qiita
概要 この記事では、RSpecにあまり馴染みがない人にもわかりやすいように、RSpecの理想的な書き方（＝コーディングルール）を説明しようとしています。 書いてあることは個人的な見解です。理性的な議論を歓迎します。 友人に語っているような文体ですのでお気をつけください。 動機 俺はみんなにRSpecを書いてほしかったんじゃない。 いいRSpecを書いてほしかったんだ(´・ω・｀) なぜかバリデーションだけ一生懸命にテストされていて自作の30行近いメソッドにテストがないとか、10行近いbeforeブロックがコピペされまくってるとか、そういうのはさ、見たくないんだ。 あと、http://betterspecs.org/ は読もう。日本語版もあるし。そこに書いてあることはここでは繰り返さないので、あしからず。 総論 はじめに ここから先は読まなくてもいいからこれだけは読んでほしい。 itブロック
RSpecで書かれたテストの高速化 / TokyuRubyKaigi10
TokyuRuby会議10（2016/05/29）
RSpecを学びながら熊本地震の災害支援ができる！期間限定でEveryday Railsのチャリティセールを実施します - give IT a try
お知らせ 僕が翻訳者の一人としてかかわった「Everyday Rails - RSpecによるRailsテスト入門」を本日から2016年5月31日まで、最低購入価格を16ドルから9ドルに値下げします。 さらに、この期間に発生した収益はすべて熊本地震の災害支援のために募金します。 Everyday Rails - RSpecによるRailsテスト入門 今回のチャリティセールはRSpecを使ったRailsのテストの書き方を学びつつ、同時に熊本地震の災害支援にも貢献できるので、プログラマのみなさんにはぜひ購入を検討してもらえると嬉しいです。 以下でこのチャリティセールに関するさらに詳しい内容を書いていきますので、興味がある方は続きを読んでいってください。 募金金額の計算ルール 「Everyday Rails - RSpecによるRailsテスト入門」（以下Everyday Rails）はLean
Rspecでfailするとデスメタルが流れるようにした - ( ꒪⌓꒪) ゆるよろ日記
あまりにもテスト通らないのでデスメタル聴き始めた— ⁰⁰⁰⁰null (@yuroyoro) 2015, 7月 2 このような事があったので自動化した。 Mac限定。 こんな感じ。successだとレベルがアガる。 事前にbash-itunes というコマンドラインツールを入れておく。 iTunesを日本語で使ってる場合、patchを当てる必要がある。 こちらを山椒 コードはこれな。 class PlayItunesReporter attr_accessor :success_track, :failure_track def initialize(options = {}) @success_track = options[:success] @failure_track = options[:failure] end def dump_summary(notification) re
使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ（注：僕基準）については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker時代の分散RSpec環境の作り方 // Speaker Deck