はじめに
昨年末からQiitaに執筆していた初心者向けのRSpec入門記事、「使えるRSpec入門」の全4回をすべて書き終えました。
各記事のリンクは以下の通りです。
- 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」
- 使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」
- 使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」
- 使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」
「使えるRSpec入門」って何?
「使えるRSpec入門」は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」をテーマにしたシリーズ記事で、略して「使えるRSpec入門」と名付けました。
僕がRSpecでRubyやRailsのテストを書いてきた経験から、「これはよく使うから重要」「ここは初心者がつまづきやすい」と思う点をピックアップして説明しています。
逆に「これはあまり使わないな-」「別に知らなくても大丈夫でしょ」と思うような機能はあえてばっさりカットしています。
これは僕のポリシーでもあるんですが、情報を提供するときは「見て見て、こんなにもたくさん集めたんだよ、すごいでしょ!!」じゃなくて、「星の数ほどある情報の中から、あなたのためにこれだけを厳選しました」という方が価値があると思っています。
「使えるRSpec入門」はもちろん後者のスタンスで書いた記事です。
「使えるRSpec入門」を書いた動機
執筆裏話として「使えるRSpec入門」を書いた動機についても軽く触れておきます。
RSpecは難しい?
第1回の記事にも書いたんですが、このシリーズを書いた理由は「RSpecはそこまで難しくないよ」ということを知ってもらうためです。
昨年の後半ぐらいから「RSpecは難しい」「RSpecって何か気に入らない」といった声をネットでちらほら見かけるようになりました。
これはRSpec 3になっていくつかの構文が変わったことも影響していると思います。
たしかに、知識ゼロの状態でRSpecのコードを初めて見たときは僕も「えっ、何これ?なんか気持ち悪い!!」って思いました。
しかし、じっくり向き合ってみると「おお、これは便利!とても合理的!」と思いましたし、コードを書くときも英語のドキュメントっぽく書けるのは僕にとっては書きやかったです。
構文が変わったのも技術的にやむを得ない部分がありましたし、RSpecの設計者がより良い結果を求めて仕様を変えたのであれば「ここで多少負担が上がっても、将来的にはペイするはず」と受け入れてもいいんじゃないかなーと僕は思っています。(「コロコロ仕様変えんな!」という人たちの気持ちも、もちろんわかるんですが。。。)
少なくとも既存のテストをアップグレードする際は Transpec という自動変換ツールがあるので、いちいち手作業で過去のテストコードを書き直す、みたいな手間は必要ありません。
もちろん、テスティングフレームワークにはそれぞれ長所と短所があり、RSpecに全く欠点がないというわけではありません。
とはいえ、僕にとってはRSpecの短所よりも長所の方が上回っているので、僕はメインのテストツールとしてまだしばらくRSpecを使い続けるつもりです。
・・・と、僕が思っていてもネットの人たちが同じように思ってくれるわけではありません。
むしろ、影響力のある人たちが否定的な発言をしたりすると、「あの人がそう言うんだから、きっとそうなんだ」と思ってしまう人の方が多いと思います。
(僕自身もあまり知識がない技術分野に関しては「影響力の大きい人の発言」によく流されることがあります、はい。。。)
「あ、RSpecってこういうふうに書けばいいのか」と思ってもらえたら大成功
このまま放っておくと、ずるずると「RSpec、あかんやーん」っていう声が増えていきそうな気がしたので、そこへ一石を投じるためにこのシリーズ記事を書こうと思いました。
有益でわかりやすい入門記事を提供することで、あまり知識がない人が「RSpec、あかんやーん」ではなく、「あ、なるほど、RSpecってこういうふうに書けばいいのか」と考えるようになってくれたら、微力ながらもネットの流れを変えられるんじゃないかなーと思ったわけです。
というわけで、「使えるRSpec入門」シリーズの執筆にはそういう意図が隠されていたりします。
RSpecのことをあまり知らなかったあなたがこのシリーズを読んで、「これでテストが書けそうな気がする」と思ってくれたら、僕にとっては大成功です。
第5回の記事も登場するかも?
実は構想としては第5回の記事も存在しています。
第5回の記事はRSpecを使う、使わないにかかわらず、「そもそもテストって何をどれくらいテストしたらいいの?」っていう問いに対する僕なりの回答です。
「RSpecの書き方はわかった、でも自分でテストを書こうとしたら何をテストしたらいいかわからなくて途方に暮れる」
「自分が書いたテストの量はこれで十分なのか、不十分なのか、自分じゃよくわからない」
・・・と思っている人の疑問に僕だったらどう答えるか、というような内容になると思います。
ただ、この内容は実は昨年の夏にソニックガーデンの有料トレーニングで講演したものとほぼ同じになります。
無料で公開してしまうと、お金を払って受講してくれた人に申し訳ないので、公開するとしたら有料コンテンツにせざるをえないかなーと思っています。
具体的な計画があるわけではありませんが、もしかするとそのうちこの第5回の記事を何らかの有料コンテンツとして公開するかもしれません。
その際はまたこのブログでお知らせします。
まとめ
というわけで今回はQiitaに書いた「使えるRSpec入門」シリーズについてあれこれ紹介してみました。
RSpecを使うにせよ、使わないにせよ、テストコードはやっぱり重要ですね。
JUnitを使い始めたときから数えると、かれこれ10年ぐらいテストコードを書いています。
今まで「あー、テスト書いてて良かった!」と思う瞬間が数え切れないぐらいたくさんありました。
テストコードを書くこと自体は多少時間を食うものですが、それでも一度テストを書いておけば、その後の開発がずいぶんと楽になります。
逆に「コードを変更するたびに手作業と目視で確認」とか「壊れていないことを祈りながらリリースする」なんてことを繰り返すのはかえって非効率なので、できるかぎり避けたいものです。
「まだまだテストを書くのは苦手~」と思っているみなさんは、ぜひ「使えるRSpec入門」を読んで勉強してみてください!
- 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」
- 使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」
- 使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」
- 使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」
あと、毎度お馴染みの「Everyday Rails - RSpecによるRailsテスト入門」もよろしくお願いします~。
Everyday Rails - RSpecによるRailsテスト入門 - Leanpub
おまけ:最近書いたQiita記事あれこれ
「使えるRSpec入門」以外で最近書いたQiita記事を紹介します。
- フィーチャスペックでテスト失敗時に自動的に save_and_open_page を実行する方法
- Rails 4.2にアップデートすると、"ArgumentError: wrong number of arguments (2 for 1)"というエラーが出てテストが失敗する場合
- Rails 4.1以降のコンソールコマンドは必ず bin/ を付けなきゃいけないの?
- 動画(スクリーンキャスト)で学ぶRubyリファクタリング(+RubyMineのTips集): divide_equally編
こちらはRubyMineアドベントカレンダー2014向けに書いた記事です。
- RubyMineアドベントカレンダー2014で集まった質問に回答します
- RubyMineのコードジャンプ機能は本当にすごい!!困ったときはCommand+Bを押すべし!
- メインの開発ツールをVimからRubyMineに変更した理由
今後も技術的なネタはQiitaで公開しようと思っているので、よかったらフォローをお願いします!