DDD ディストーション駆動開発

エレキギターと音楽とRubyを愛するフルテンエンジニアのblog

RSpec楽しい! Everyday Rails - RSpecによるRailsテスト入門

テスト書くのは結構楽しい

テストが大好きなエンジニア、ってあまりいないと思います。やらなきゃいかんからやってる、って人が多いんじゃないでしょうか。私もこれまで「テスト楽しい」と思ったことはなかったです。

RSpecがちょっと書けるようになってきて、テスト作業の一部がコーディング置き換わり、テスト楽しい!! って思えるようになったのは最近のことです。今思えば「RSpec = テスト」テスト、っていう言葉の響きが嫌いだったんですね。

Everyday Rails - RSpecによるRailsテスト入門

jnchitoさんのQiita記事を参考にRspecを書き始めて、下の本を買っちゃいました。

とっつきやすくて、かつ、徐々に理解を深めていけるように構成されていて、自分にはThe RSpec  Book より合っているようで、すいすい読み進められました。

leanpub.com

テストが書けなかった自分が、書けなかった理由を振り返る

  • 難しく考えすぎてた
  • 書くタイミングが悪かった

こんなところかなと思います。

テストは別に難しくない

describe , it , expect().to eq() さえ覚えれば最低限のテストが書ける。難しくない。

Dryに、とかFactoryGirlとか忘れて、とりあえずこれ使って書いてみて、その後で色々覚えればいいや、って思ったら気楽に書き始められました。

で、とりあえずのテストを書いてみたら、FactoryGirlの扱いや様々なマッチャ、RSpecの文法もすいすい入ってくるようになりました。習うより慣れろ、ですね。

qiita.com

タイミング:できるだけ早い段階で書くこと

最初からテストファーストはなかなか難しいので、テストを書くべきメソッドがあらあらで仕上がってきたらspecを書き始める、くらいのタイミングが私は好きです。

これくらいのタイミングだと、メソッドがやるべきことも明確にわかっているので、テストする項目もすらすら出てきますし、テスト書いていると、考慮できていないケースを発見できたりします。

メソッドが完全に仕上がってから書くより、あらあらの段階からspecがあるほうがデグレの心配せずにコーディングできるので、効率よくメソッドを仕上げていけると思います。

specは後日書きます、は最悪です。開発時のメリットを捨て、仕様がしっかり詰まった脳みそもない状態で書くspecはただただ苦行です。

テストを書くと開発が早く、楽しくなる。

本番コード書き終わる→テスト書く、という考え方だから、「テスト書く時間を確保する=開発遅くなる」と思ってしまうだけで、テストも開発の一部だし、テスト書きながら開発するほうが最終的には効率も絶対良いと思うのです。

書いたコードを画面で動かしてみたり、コンソールで試し打ちしたり、少なからずテスト的なことをやりながら開発している人が殆どだと思うのですが、テスト書けばいろんなパターンを網羅してくれるので試し打ちより楽です。

コードレビュー指摘もらった際の修正も、テストがあれば楽々です。ひととおりのテストを実施した後でコードチェックを受け、通ったらマージ、というフローをとっている方が多いと思うのですが、コードチェック指摘に対応する場合、もう一度全テスト通すことになりますよね。RSpec書いていれば楽勝ですね。

まとめ

テスト書くと開発が遅くなる、というのは、開発=コーディングという捉え方をしている場合においてはそうかもしれませんが、開発=着手〜納品(マージだったり、本番リリースだったり) で考えると、遅くなるということはないと思っています。

まして、動き続けるコードに対して開発は延々と続いていくので、テストがあれば、後にそのコードを触る人の効率も上がるはずです。