僕のCode to Test Ratio歴

Ruby on Railsでの開発では、その規模の大小問わず、短期的・長期的問わず、最低限の品質を確保するためにテストコードの作成と自動化は「必ず」行うべきである、という考えを僕は持っている。つまり、テストコードのないRailsの成果物は、非常識きわまりなく、構造計算が一切行われていない建物と一緒。もしそんな開発プロジェクトがあれば、それは国会で取り上げられる程の騒ぎにならなければいけない事態であり、IT業界からご退場願わなければならない、と思っている。

さて、RoRでは、常に「自分がテストにどれくらい関わったのか」という指標を確認できるように、rake statsというタスクが標準で提供されている。これにより、実装コード行数とテストコード行数の割合がサクッと出てくる。もちろんカバレッジ率ではなく、総行数に関する指標であるので、あくまで参考値ではあるが、それを意識するのとしないのとでは大違いだろう。

rake statsは、railsコマンドでプロジェクト一式を生成した直後から使用することができる。

+———————-+——-+——-+———+———+—–+——-+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +———————-+——-+——-+———+———+—–+——-+ | Controllers | 7 | 3 | 1 | 0 | 0 | 0 | | Helpers | 3 | 2 | 0 | 0 | 0 | 0 | | Models | 0 | 0 | 0 | 0 | 0 | 0 | | Libraries | 0 | 0 | 0 | 0 | 0 | 0 | | Components | 0 | 0 | 0 | 0 | 0 | 0 | | Integration tests | 0 | 0 | 0 | 0 | 0 | 0 | | Functional tests | 0 | 0 | 0 | 0 | 0 | 0 | | Unit tests | 0 | 0 | 0 | 0 | 0 | 0 | +———————-+——-+——-+———+———+—–+——-+ | Total | 10 | 5 | 1 | 0 | 0 | 0 | +———————-+——-+——-+———+———+—–+——-+ Code LOC: 5 Test LOC: 0 Code to Test Ratio: 1:0.0

こんな感じで出力される。Code to Test Ratioの数字は、実装コードの総行数を1とした場合の、テストコードの総行数の割合、である。この数字を意識することが必要。

では、この数字を評価するための参考値が何かあるのか?というと、お堅い大企業ではよく品質管理部門が「1関数あたりに必要なテスト項目数」とか決めていたりするけれど、ことRailsでのそういった指標をGoogleで探しても、参考になるような情報は見つけられなかった。

なので、僕がRailsで開発したものについて、Code to Test Ratioの数字(これは客観的な指標)と、テストをやりきったかどうかの感覚(これは僕の主観的な指標)をここにいくつか提示してみよう。

  • ToDo管理アプリ - 1:3.1 - これでもかっとテストコードを書いた。

  • ブックマーク共有アプリ(承認機能付き) - 1:1.4 - ロジック・画面遷移・各メソッドについてはほぼ網羅。しかしViewに関するテスト(動的内容が正しいタグの場所に出力されたか)は甘かった。

  • facebookアプリ - 1:2.3 ほぼテストコードを記述。しかしFacebook APIを利用する部分のテストが甘い。

非常に少ないケースから、さらに主観的な傾向を読み取るとしたら、

  • 3.0〜 - ほぼ大丈夫。安心レベル。

  • 2.0〜3.0 - 一部抜けがあるものの、運用を継続できるレベル。

  • 1.0〜2.0 - テストコードはあるが、大きく抜けている部分がある可能性大。運用開始はできても継続成長は無理。

  • 0.0〜1.0 - 話にならない。運用開始直後から多数の不具合が発見されること確実。

という感じになる、かな。

もしRuby on Railsを使って作られたサービスやシステムで、rake statsにより得られたCode to Test Ratioの値が、例えば「2.0」を下回っていた場合は、そのシステムの開発ベンダーに今すぐに問い合わせをすべきだ。そして、不幸にも最も酷い「0.0〜1.0」の範囲内だった場合は、開発ベンダーによる詐欺行為を受けていると認識して構わない、と考えて良いと思う、個人的には。

良い子のみんな、上記が「理想論」とか「学術的」とか、決して思わないように。上記は、システム開発をする上で「最も当然」なことであり、それが信頼感、達成感、安心感、責任感を顧客に提供することになり、初めて「ビジネス」という言葉が使えるようになるんだ、という考えで、Ruby on Railsというものに取り組むべきである。僕はそう考える。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて