[Rails] RSpecをやる前に知っておきたかったこと｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 今さらですが、RSpecをやる前に知っておきたかったことを記事にしました。少しさかのぼって、ソフトウェアのテストについても最初に簡単にまとめてみました。 ソフトウェアのテストとは まず、広い意味でのソフトウェアテストは「人間による目視チェック」のようなものも含まれる点にご注意ください。 ソフトウェアの動作確認をどのように行うかは、ソフトウェア開発において常に大きな課題です。 当然ながら、ソフトウェアの動作確認を思い付きでやっていると漏れが発生しやすく、確認のたびにチェック内容が変わってしまったりするので好ましくありません。 そこで、ソフトウェアのテスト方法を体系化し、 誰がやっても同じようにテストできる方法 誰でもテスト計画を策定できる手法 が模索されてきました。 個別のテスト実施はドラゴン桜の名言でいうところの「作業」であり、ひとつひとつはそれほど重
![[Rails] RSpecをやる前に知っておきたかったこと｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/0df40072c11178520fcb31a3c122401dbda1bc55/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2012%2F05%2Frspec_eyecatch.png)
rubyの`# =>`を検証するやつを書いた - Qiita
とか書いてあるじゃないですか。# => を挟んで、左辺が式で右辺がその結果というやつ。 それ、でも、どんだけ信じていいの? そのコメント作るだけであれば JoshCheek/seeing_is_believing で作れるんだけど、逆がないんだよね。 というわけで作った。 https://rubygems.org/gems/xmp2assert 実装について ごくラフなアイディアとしては actual # => expected って書いてあったら assert_equal(expected, actual) に変換する。これが着想。 とはいえこの式はRubyの式なわけで、正規表現置換のような生易しいことにはならない。Ripperでがんばってコメント位置を発見して、その直前にある式を…… みたいなのをやっていて非常に面倒。 このコメントはコメントであるがゆえに実行時には読み飛ばされるので、
Chain RSpec Matchers for Improved Test Readability
I’ve recently journeyed back into the world of Rails development after an extended stay in more functional languages. One aspect of Ruby that always delights me is its focus on readability. With this focus, along with the ability to fold certain structures, I set out to improve a wordy test. The original test looked like this: select_multiple_from "Which of these apply to you?", [ "I read the New
RSpec Expectations Cheat Sheet
Continuing the from the previous post, here is a cheat sheet for RSpec’s assertion library: RSpec::Expectations. RSpec is a mature, feature-packed testing framework, but the documentation can be difficult to navigate. As an alternative to the official documentation, this cheat sheet contains short example code to demonstrate all the built-in expectation matchers. These examples were created with R
Minitest でテスト、Rails のテスト (その1) - Qiita
だいたいぼくは Rails のプロジェクトではテストフレームワークとして Minitest を使っているのですが、だいたい「RSpec しか書いたことなくて Minitest わかんねー」という苦情をいただくので、なんとなく Minitest について、なんか使い方だとか、書き方のコツだとか、なんかそんなようなやつをまとめていこうと思います。 内容は「Minitest Cookbook」の「Rails Recipes」の章を思いっきり参考にさせてもらっています。なので Minitest 自体の説明は少なくて Rails のテストに特化した内容となっています。この本はほとんど唯一の Minitest 本だと思うし、ここで紹介する Rails 絡み以外の部分も良い内容なので読んでおくといいでしょう (そこそこ高いけど) 。 ちなみにこれは「その1」で、まだまだ続く予定ですがいつ書くかは未定です
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
Elixir コードもレビューできる Ebert の紹介 - Qiita
Elixir コードもレビューしてくれるサービス Ebert が Plataformatec から以前にリリースされていたので、そちらを紹介します。 GitHub の公開リポジトリであれば無料で使えるとのことで早速使ってみました。 概要 タイトル通り Elixir コードもレビューしてくれるサービスです。 対応言語は最初 Elixir だけかと思っていましたが、実は結構いろいろとサポートしているようです。 Elixir については Credo を使ってレビューしてくれます。 レビュータイミングは日ごとと Pull Request が来た時です。 レビュー結果の例として ecto のリポジトリで試した結果があるので参考になります。 設定方法 add a new repository から画面上の指示に従って作ることができます。 GitHub 認証でアカウントを作った後、連携のための GitH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FakerElixir - FakerElixir generates fake data for you.
Docker時代の分散RSpec環境の作り方 // Speaker Deck
RSpecのフォーマッターの出力結果を任意のデータストアに保存できるgem rspec-storageを作った - Qiita
GitHub - pragdave/quixir: Property-based testing for Elixir
Rails RSpecの基本 ~Controller編~ - Qiita
Integration Testing Phoenix with Wallaby
Integration Testing Phoenix With Wallaby
Elixir + Phoenix + ESpecでBDDするまで - Qiita
GitHub - blowmage/minitest-rails-capybara: Capybara integration for MiniTest::Rails
Automatically reloading tests with Elixir Phoenix and ExUnit on Ubuntu
Testing Phoenix Views
HTTP unit tests using ExVCR
sinatraなアプリケーションをminitestするための下準備 - Qiita
