RSpecのコードの書き方に関するQiita記事を書きました

お知らせ

Qiitaに「【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法」という」記事を書きました。

qiita.com

この記事はざっくりいうと、こんなRSpecのコードよりも、

describe 'キャンセル処理' do
  let(:user) { create :user }
  let(:reservation) {
    create :reservation,
      user: user,
      start_at: '2017-08-10 10:00'.in_time_zone
  }
  context '24時間前をすぎるとキャンセル料が発生する' do
    before do
      travel_to '2017-08-09 10:00'.in_time_zone
      reservation.cancel!
    end
    after { travel_back }
    let(:billing) { user.billings.first }

    it { expect(user.billings.count).to eq 1 }
    it { expect(billing.amount).to eq 500 }
  end
end

こんなコードの方がいいよね？というお話です。

describe 'キャンセル処理' do
  let(:user) { create :user }
  let(:reservation) {
    create :reservation,
      user: user,
      start_at: '2017-08-10 10:00'.in_time_zone
  }
  context '24時間前をすぎた場合' do
    before do
      travel_to '2017-08-09 10:00'.in_time_zone
    end
    after { travel_back }

    it 'キャンセルするとキャンセル料が発生する' do
      reservation.cancel!

      expect(user.billings.count).to eq 1

      billing = user.billings.first
      expect(billing.amount).to eq 500
    end
  end
end

「えっ、なんで？」というその理由はQiita記事の中に詳しく書いてあるので、そちらを参照してください！

qiita.com

最近の僕が書いてるテストコードの傾向

一時期は僕もletやbeforeやsubjectをあれこれ駆使して、DRYでカッコいいテストコードを書こうとしていました。
しかし、最近はそういったテストコードはやめて雑にコードを書くようにしています。

RSpecの機能を駆使しまくって書いたテストコードは書くのにも時間がかかるし、書いてからしばらく時間が経つと、ぱっと見てよくわからなくなるし、新しいテストコードを追加するときも「これ、どこに追加したらいいんだ・・・？？」と迷いがちになります。
なので結局、現在は「愚直にベタ書きして上から下に素直に読めるコードを書くのが一番いいや」という考えに至っています。

まあ、RSpecの機能を使った方が効率が明らかによくて可読性や保守性も落ちない、というときは、RSpecの機能も積極的に使うんですけどね。

そのあたりの話は以前書いたこちらのQiita記事に書いてあります。

qiita.com

まとめ

そういえば今回書いたのはおよそ2ヶ月ぶりのQiita記事でした。
この夏は本の出版準備やらなんやらでバタバタしてたので、ブログやQiitaを書く時間があまりなかったんですよねえ。

とはいえ、別に書くのをやめたわけじゃないので、書くネタと書く時間ができたらまたなんか書きます。
よかったら僕のQiitaアカウントもフォローしてやってくださいね〜。

qiita.com

あわせて読みたい

Qiita記事の中で使ったArrange、Act、Assert（AAA）は先日読んだ「Effective Testing with RSpec 3」に載っていたテストコードの原則です。
本で学んだ知識をさっそく実戦で使ってみましたw

blog.jnito.com

【洋書Q＆A】どうやって洋書を読んでるの？どれくらい時間がかかるの？という質問に答えてみた

はじめに

昨日、「こんな洋書を読んだよー」っていうブログを書いたら、Twitterでこんな質問をもらいました。

どのように洋書を読んでいますか？
読み切るのにどれくらいかかりましたか？
洋書を読むと和書より頭に残らないことが多いので、ぜひ参考にしたいです。

— urimaro (@urimaro) 2017年9月11日

どれだけ役に立つかわかりませんが、140文字で返信するには短すぎるのでこのブログに返信を書いてみます。

備考：「洋書」の定義

ここでいう「洋書」とは、「英語で書かれたプログラマ向けの技術書」のことを指します。

たしかに洋書の内容は頭に残りにくい

質問主のurimaroさんは「洋書を読むと和書より頭に残らないことが多い」とおっしゃっていますが、その感覚は僕もわかります。
英語はそこそこ得意とはいえ、母国語と同じレベルで英語を読めるほど僕の英語スキルは高くないです。

わかりにくい表現かもしれませんが、日本語を読むときって写真を撮るように文章が読めるんですよね。
ページを開いてその瞬間に目に飛び込んできた文字で、だいたい内容が把握できる感じです。

もちろん詳細はしっかり読まないとわからないんですが、ざっくりした内容はページを上から下にざーっとスキャンするだけで理解できる気がします。

洋書だとそういう読み方をするのはちょっと難しいです。
昔に比べると多少できるようになってきましたが、日本語の本に比べるとまだまだです。

「頭に残る、残らない」もこの理由に近いのかなーと思ったりします。
日本語は読むというより、「見る」だけで頭に入る、頭に残る。（写真を撮って脳内のアルバムに残すように）
英語はそうはいかない（ので、頭に残りづらい）。

もちろん英語でも100%抜け落ちていくわけではないですが、「洋書を読むと和書より頭に残らない」というのは僕も同感です。

洋書を読み切るのにかかる時間は？

読み切るのにかかる時間はまちまちですねー。
これは洋書・和書に関係なく、です。
速い、遅いは次のような条件によって変わってきます。

• 自分に予備知識がある技術書は速い。そうでなければ遅い。
• ばーっと読んで要点だけつかみたい技術書なら速い。じっくり理解する必要がある技術書は遅い。

はい、当たり前の話ですね。

先日読んだ「Effective Testing with RSpec 3」の場合は、RSpecに関する予備知識はすでにあるし、もともと書評を書くためだったので、ばーっと読みながら「この内容をブログに書こう」というポイントを探していく感じでした。

なので、さっきの条件でいうと「速い x 速い」になるので、結構速く読み終わりました。
具体的には土日の2日間、トータルで7-8時間ぐらいです（それでもまあまあかかってるか）。

予備知識がない技術書を読むときなんかは、日本語の本でも読むのは遅いです。
（だから、まだ読み切ってない技術書が何冊かあります・・・）

どんなふうに洋書を読む？

洋書の読み方については昨日のブログでもちらっと書いたんですが、「全部理解しようとせず、多少わかりにくい内容があってもどんどん読み進める」というのが一番のポイントかな、と思っています。

そりゃもちろん全部理解するのが理想的ですが、一般的な日本人は和書と同じレベルで洋書を理解するのは無理です。
「細かいところはわからないけど、だいたい6割ぐらい理解できてるかなー」と思えれば、とりあえずは十分なんじゃないでしょうか。

知らない単語が出てきたときも、最初は調べずにとりあえず読み進めていくと、何度か同じ単語に遭遇するうちに、「あー、たぶんこんな意味なんだろうなあ」というのがだんだんつかめてきたりします。

「結構頻繁に登場するし、何度遭遇してもまったく意味の予想がつかん」というときだけ、辞書を引いて意味を調べます。

洋書の読みやすさは著者によっても異なる

あと、日本語でも同じですが、文章の読みやすさはその本を書いた人によって変わってきます。
「1文をやたら伸ばしたがる人」や「慣用句っぽいフレーズをやたら織り交ぜてくる人」の文章は読みにくいです。

何冊か洋書を読んでいると、「あ、この人の英語はわかりやすいな」とか「うーん、この人の英語は非ネイティブにはちょっと厳しい・・・」みたいな感じで、著者のクセが見えてきます。
1冊目に運悪く「読みにくい英語を書く人」にあたると不運ですが、めげずに何冊か読んでいくと「あ、この洋書はなんかわかりやすいぞ」という洋書にめぐりあえるかもしれません。

READMEの英語が読めれば洋書も大丈夫！？

とはいえ、技術書に登場する単語や言い回しはだいたいよく似たものが登場します。
GitHubのREADMEが理解できる人なら、洋書もだいたい理解できるはずです。

特に、コードがたくさん載ってれば載ってるほど、理解しやすくなりますね。
上から下へと順に読まずに、先にコードを読んでから前の文章に戻る、という読み方もよくやります。

なんかまとまりのない話になっていますが、どんなふうに洋書を読んでるかなーと考えたときに思い浮かぶ話はこんな感じです。

余談：日本語に翻訳されたからといって読みやすいとは限らない

「でもやっぱり英語で読むのはいやだなー。あの技術書が日本語に翻訳された嬉しいのになー」と思う人も多いかもしれません。
ただ、翻訳は翻訳で「翻訳の質」が翻訳者によって大きく異なるのが難点です。

僕も「日本語版が出てるなら、日本語版でいいかー」と思って日本語に翻訳された技術書を読むときがありますが、たまに「うわ、これはつらい・・・」と思う翻訳に出くわすことがあります。
わかりづらい翻訳を連発されると、「うーん、原著を買うべきだったかな」と思ってしまいます。

僕が思うに、受験英語っぽい訳し方（長文を後ろから前へ訳すような訳し方）になっている日本語訳は非常に読みにくいですね。
あと、「もしかしてこの人、ふつうに日本語で文章を書かせてもあまり文章がうまくないのでは？」と思うケースもときどきあります😓

餅は餅屋、プロの翻訳者が訳した本は読みやすい

全部が全部、とは言いませんが、「普段はふつうに現場でコードを書いてる技術者ですが、今回初めて翻訳にチャレンジしてみました！」みたいな人が翻訳をしている場合は、読みにくい翻訳になっていることが多い気がします。

逆に「昔から何冊も技術書を訳しているプロの翻訳者」だとハズレを引く可能性が少ないです。
個人的な感想だと、長尾高弘さんという方が訳した技術書はどれも読みやすくて、「さすがプロの仕事だなあ」といつも感心しています。

プログラミング言語 Ruby

詳説 正規表現 第3版

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

まとめ

というわけで、このエントリでは洋書の読み方について、思うところをあれこれと書いてみました。
思いついたことをつらつら書いていっただけなので、あまりまとまっていませんが、いくつか参考になる部分が見つかれば幸いです。

和書に比べると洋書はニッチな技術書がたくさん出版されているので、技術者の人は絶対洋書が読めた方がお得です！
「この技術は気になるな－。でも日本語の本はまったく出てないんだよなあ」と思うときは、ぜひ洋書にチャレンジしてみてください。
「この技術が知りたい」というモチベーションさえあれば、なんとかなるはずです。

もし、洋書を読んでいて行き詰まりを感じたら、僕が今回書いたような話が参考になるかもしれません。
最後は経験がモノを言う、みたいなところもあるので、1冊で挫折せずに何冊も読んでみるのがいいと思います。

がんばって「翻訳を待たずに洋書が読める技術者」を目指しましょう！

あわせて読みたい

昨日書いた「Effective Testing with RSpec 3（洋書）」の書評です。
blog.jnito.com

「そもそも基本的な英語力が低いんです」という方は、このエントリを読むと参考になりそうな情報が載っているかもしれません。
blog.jnito.com

僕はもともと英語は得意な方でした。なんで得意なのかはこのエントリに書いてあります。
blog.jnito.com

【書評】RSpecの初心者から上級者まで役立つ！「Effective Testing with RSpec 3」を読みました

はじめに

数ヶ月前、RSpecコミッタのYuji Nakayamaさん（@nkym37）から突然連絡がきて、「リードメンテナのMyron Marstonが今度RSpecの本を出版するんだけど、Myronが日本人のレビュアーを探している。なので伊藤さん、レビュー記事を書いてみない？」というお話を受けました。
「はい、興味あります！書きます！！」ということで、二つ返事でオファーを受けることにしました😄

というわけで、今回読んだのがこちらの「Effective Testing with RSpec 3」です。

Effective Testing With Rspec 3: Build Ruby Apps With Confidence

このエントリではこの本の概要と僕個人の感想をいろいろ書いてみます。
（本を提供してくれたMyron Marstonさん、どうもありがとうございます！日々進めてくれているRSpecの開発にも感謝します！）

僕はEPUB版をiPadに入れて読みました。

本の構成

本書は5つのパート、15の章に分かれています。
対象となるRSpecのバージョンは3.6です（2017年9月時点での最新バージョン）。

以下に各パートの概要を述べていきます。

パート1 「さあはじめよう」

簡単なRubyプログラムをRSpecでテストしながら、RSpecの基本を学ぶパートです。
3章ではテストの種類や良いテストや悪いテストについて説明しています。

• 1章 RSpecをはじめよう
• 2章 Specを書いて実行する
• 3章 RSpec Wayとは

パート2 「RSpecでアプリを作る」

SinatraとSequelで簡単なWeb APIを開発し、それをいろいろなレベルごとにテストするパートです。
パート1よりもさらに実践的なテクニックが学べます。

• 4章 外側から作る: 受け入れスペック（Acceptance Specs）
• 5章 個別にテストする: ユニットスペック（Unit Specs）
• 6章 実物に近づける: 統合スペック（Integration Specs）

パート3 「RSpec Coreについて詳しく」

it/example/specify、describe/context、before/afterフック、メタデータ、spec_helper.rbの設定など、RSpecに用意されている各種機能を掘り下げて説明するパートです。

• 7章 exampleの構築と整理
• 8章 メタデータでスペックをさらに便利に
• 9章 RSpecを設定する

パート4 「RSpec Expectationsについて詳しく」

エクスペクテーションが動作する仕組みやデフォルトで用意されているマッチャの仕様、独自のマッチャの作成など、データを検証するための機能やテクニックを詳しく解説するパートです。

• 10章 RSpecのエクスペクテーションを詳しく知る
• 11章 RSpec Expecationsに含まれるマッチャ
• 12章 カスタムマッチャを作成する

パート5 「RSpec Mocksについて詳しく」

単にモックの使い方を説明するだけでなく、モックやスタブの違い、モックの正しい使い方なんかも詳しく説明してくれるパートです。

• 13章 テストダブルを理解する
• 14章 テストダブルをカスタマイズする
• 15章 効果的にテストダブルを使用する

全体的な感想

僕個人の感想としては非常に良かったです！いや、ほんとに。お世辞抜きで。
さすがRSpecのリードメンテナが執筆に携わっているだけあって、すごく詳細にRSpecの機能が紹介されています。
RSpecにはそれなりに詳しい僕でも知らない機能がいくつかありました。

また、機能を説明する際のユースケースやサンプルコードもかなり実践的なものが多かったです。
本を読みながら「うん、たしかにそういうケースはよくある！」と大きくうなずけるポイントが多数ありました。
なので、本で学んだ内容の多くはすぐに実務のテストコードで適用できるはずです。
僕も早速この本で知った"filter_run_excluding"を使います！

さらに、この本が説明するのはRSpecの機能だけではありません。
どんなテストコードが良くて、どんなテストコードが悪いのか、という「効果的（effective）なテストコードの書き方」についても説明してくれています。
僕の周りでも「どんなテストを書けばいいのかわからない」という声はよく聞くので、そういう人たちには打ってつけの内容になっています。
（「何をテストしないか、を検討すべし」とか、初心者の人はあまり考えたことがないのでは？）

もちろん、高度な内容だけでなく、最初のパートではRSpecの基本から説明してくれるので、RSpecをまったく知らない初心者も付いていけるようにちゃんと配慮されています。
RSpecの設計思想なども要所要所で語られているので、「RSpecは難しくて嫌い」と言っている人たちもこの本を読むとRSpecに対する考え方が少し変わるかもしれません。

というわけで、RSpecの初心者でも上級者でもすごくためになりますし、RSpecに限定されない「テストコードのベストプラクティス」や「モックの使用ガイドライン」まで説明されているところも素晴らしいと思いました。

細かい部分の感想など

パート2ではRailsではなく、あえてSinatraとSequelを使っているところが興味深かったです。
Railsを使わないのは「Railsは機能が多すぎるのと、ジェネレータがあるためにテストのセットアップ手順の勉強にならないから」ということでした。

最初は「えー、なんでRailsじゃないの？」と思ったのですが、普段あまり使わないSinatraとSequelの使い方がわかって、思わぬところで勉強になりました。
というか、いかに普段Railsのおかげで自分たちが楽をしているか（悪く言えば、いかに甘やかされているのか）ということを痛感しました。

ちなみに、本書の最後に出てくる付録パートで、rspec-railsの基本はさらっと説明されています。

あと、本文を読みながら思ったのは「RSpecってやっぱり、英語として読めるテストコードを強く意識してるんだなあ」ということです。
もちろん、ある程度までは「英語として読めるテストコード」は僕たち日本人にとっても嬉しいのですが、行きすぎるとそのこだわりがいまいちピンと来ないところが出てきます。

たとえば、本文の中で、

expect([]).to start_with( be_within(0.1).of(Math::PI) )

と書くよりも、

expect([]).to start_with( a_value_within(0.1).of(Math::PI) )

って書けた方が英語として読みやすいでしょ？という説明がありました。
ですが、日本人の僕からすると、「え？ああ、そう言われてみれば、そう・・・かな？？🤔」と思ってしまいました。
この点はRSpecを読み書きする上で、英語ネイティブの人と非英語ネイティブの人の壁を少し感じる部分ですね。

本文の英語は平易で読みやすい

さて、この本はまだ翻訳されていないので英語で読む必要があります。
普段洋書を読まない人は「洋書なんて無理無理！！」と思うかもしれませんが、本書の英語は全体的に平易で読みやすいです。
コードも多いので、コードと一緒に英語を読めば、だいたい意味はつかめるんじゃないでしょうか。

洋書を読む上で必要なのは、

• 「この技術が知りたい！」という強いモチベーション
• 全部理解しようとせず、わかりにくいところがあっても立ち止まらずに読み進める勢い

の2つです。
これがあればなんとか読破できると思います。

公式サイトで販売している電子書籍版であれば、思い立ったときにすぐ手に入れることができるので、勇気を出して購入してみてください！

• Effective Testing with RSpec 3: Build Ruby Apps with Confidence by Myron Marston and Ian Dees | The Pragmatic Bookshelf

まとめ

というわけでこのエントリでは、先日発売された「Effective Testing with RSpec 3」の書評を書いてみました。

RSpecそのものにフォーカスした技術書といえば、これまで「The RSpec Book」しか選択肢がありませんでした。

The RSpec Book (Professional Ruby Series)

「The RSpec Book」もRSpecを学ぶ上では非常に良かったのですが、バージョンが古いのと、RSpec以外のテストフレームワーク（Cucumber）が占める割合が高い点がちょっと残念でした。

今回登場した「Effective Testing with RSpec 3」は、今までの定番だった「The RSpec Book」を見事にリプレースする出来になっていると思います。
「今風のRSpecの書き方を体系的に学びたい」という人にとっては最適な一冊になっているので、ぜひ一度読んでみてください。

Effective Testing With Rspec 3: Build Ruby Apps With Confidence

最後に宣伝: 「プロを目指す人のためのRuby入門」もよろしくお願いします🙇

このブログでも何度か紹介していますが、僕も現在本を書いているところです。
「プロを目指す人のためのRuby入門」というRubyの入門書で、「Effective Testing with RSpec 3」に負けないぐらい実践的な内容を書いたつもりです。
2017年11月に発売予定ですので、こちらもぜひよろしくお願いします！
blog.jnito.com

あわせて読みたい

伊藤さんはいつもどんなふうに洋書を読んでるの？という質問を受けたので、それに対する回答をつらつらと書いてみました。
blog.jnito.com