【Rspec】テストコードを書く文化を形成するまでのロードマップ

みなさんはテストコードを書いていますか？

新規のプロダクトでは今や当たり前になってきているテストコードですが、既存プロダクトだとテストがないことがあるのもまた事実です。

今回、仕事で既存プロダクトににテストコードを追加したり、それを自走し出すまでにやったことをまとめてみました。

これからテストコードを始める人、既存プロダクトにテストコードを追加しようとしている方のヒントに慣れば幸いです。

そもそもなぜテストコードが必要なのか?

テストコードを書くことで様々な恩恵を得られます。詳細に関しては下記の記事などでも記載があるので本記事では詳細は割愛します。

なぜテストコードを書く必要があるのか？ – Qiita

開発時にテストコードを追加するのはたしかに一時的にコストが増えます。

しかし、プロダクトが数ヶ月、数年先も生き続けるのであれば、絶対にそのコストは簡単に取り返せるようになります。

また、適切にテストコードが書かれているプロダクトではバージョンアップや大規模なリファクタリングといった選択肢も増やすことができます。

本記事ではテストの必要性については詳しく触れませんが、文化づくりをする上では「なぜテストコードを書くのか」を根付かせることも非常に重要と思っています。

テストコードを書くための前準備

まずはプロジェクトでテストコードを書けるように最低限の環境を整える必要があります。

自動テストをCIに組み込む

テストコードを書いても見えるところになければないのと同じです。CI機構があるのであれば、必ず組み込むようにしてください。

これにより、開発者がマージリクエストを作る度に自動テストを意識するようになります。

まずは見える化する意味でもCIに組み込むのが重要です。

テストカバレッジを計測する

CIと同じタイミングで、テストのカバレッジ率も計測し表示するようにしました。

カバレッジ率とは、全体のコードのうちテストコードがどこまで網羅しているかを示す割合です。上記の画像の例では473行のコードのうち455行が自動テストで実行されていることを示しています。

カバレッジを計測することのメリットは、新しいコードに対してテストコードが書かれていることが判別しやすくなることです。

というのも、理想は新しいコードを書く度に同時にテストコードも書かれるのが当たり前になっている状態です。カバレッジがCI時に計測されることで、新規コードのテストコードが漏れていなさそうなことがわかります。

ただし、カバレッジ率はあくまで指標なので注意。

テストコードのための勉強会を開催する

いざCIを導入したとしても、すぐにテストが書かれるわけではありません。

今までテストコードを書いたことがないチームであれば、テストコードへのハードルはかなり高いと思います。

そのハードルを下げる目的でテストコード勉強会としてモブプロを開催しました。

ここのコストを書けることで、後々の開発に効いてきます。

使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 – Qiita

プロジェクトで自走するためのテストコードのルールや文化

上記で最低限テストコードを書くための準備ができました。

ここからが本番で、実際にコードを書く度に自然とテストコードを書くようになるためにやってきたことをかきました。

見本となるテストコードを書いておく

RSpec.describe EventsController, type: :request do
  let!(:event) { FactoryBot.create(:event) }

  describe 'GET /events', :login do
    context 'for admin' do
      it 'return http status 200' do
        get events_path
        expect(response).to have_http_status(200)
      end
    end
  end
end

最低限、プロジェクト特性上クリティカルな箇所（マネタイズポイントやユーザーフォームなど）などの主要な部分数カ所だけでもいいので実際にテストを書いておくようにしています。

テストコードの環境だけあってもなかなか書いてもらう文化は育ちにくいので、サンプルとなるようなコードを書いておくと新しいコード追加時の参考にもなります。