更新日: 2015年7月14日
RSpec

RSpec & Capybara の雑感

RSpec & Capybara を使うと、テストコードで自由自在に色んな操作をできるので基本的にとても大好きです。2年ほど前に Rails 4 の学習を始めた時に取り組んだ Rails チュートリアルで、RSpec と Capybara の基本を学びました。Rails チュートリアルはオンラインで読めて、かつテスト駆動開発を学べる、とても貴重な Rails の学習チュートリアルです。

Ruby on Rails チュートリアル：実例を使って Rails を学ぼう

今でも読みますけど、本当に最高のチュートリアルだと思う。

【お知らせ】英単語を画像イメージで楽に暗記できる辞書サイトを作りました。英語学習中の方は、ぜひご利用ください！

画像付き英語辞書 Imagict | 英単語をイメージで暗記
【開発記録】
英単語を画像イメージで暗記できる英語辞書サービスを作って公開しました

それを踏まえまして… 最近遅ればせながら RSpec 3 でテストを書くようになったのですが、expect(subject)/is_expected, be_true/be_truthy, be_false/be_falsy, describe/context/feature/scenario, let/given, before/background などの使い分けとかは、ちょっと面倒だなあ…と感じるようになってきた。feature, scenario, given, background は Capybara の DSL によるエイリアスではあるのですけど。

同じことを実現するのに書き方の種類が多いと、どれを使うべきか迷ってしまうし覚えるの大変です。個人的には describe, let, before と specify { expect(subject).to … } だけあればとりあえずは事足りるかな〜とも思います。あと be_*** の代わりに、to eq *** だけ使うとかするとさらにシンプル。

そのほうが覚えること少なくて楽ですし、初めて RSpec 書く人にも敷居が低いと感じることが多いですので。RSpec のテストコードを書いたり読んだりする上で最も重要だと感じるのは、とにかくどこから読んでも、たいして頭を使わずに一瞬で理解できることだと考えています。

it を使うとすっきり書けるのは良い点なのですけど、it が何を指してるのか一瞬で把握できないと、それだけで読むのに若干ストレスを感じてしまいます。it を使う場合は、間近の describe の冒頭で subject を書いて it が何を指してるのかすぐに分かるように書いてあると、読むほうはありがたいです。

また、メンテナンス性も大事ではあるけれども、RSpec のテストコードは頑なに DRY 違反をなくすのにこだわるよりも、可読性を優先したほうが良いというのも、今のところ自分がテストコードを書く際の方針です。

最近 Rails で RSpec のテストコードをよく書いているので、RSpec & Capybara についての日記でした。シンプルかつ可読性の良さを保ちつつ、メンテナンス性もそこそこ良い、そんなテストコードを書いていきたいですね。