JavaScriptでカバレッジを取得する

CodeZine / 2014年9月19日 14時0分

図14 CodeZineページのカバレッジ

 本連載は、テストコードをこれから書こうと考えているJavaScript技術者を対象に、テストコードの意義からテスト駆動開発、JavaScriptでのテストコードの書き方、継続的インテグレーションなど、テスト全般にわたって解説します。また、原理原則だけでなくWhyから説明し、チームメンバーを巻き込みながら開発現場に活かせる考え方を総合的に解説します。第6回目の本稿は、JavaScriptでテストを動かし、JSCoverでカバレッジを取得する方法を説明します。

■対象読者

JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 ■カバレッジとは

 ソフトウェアをテストする際の重要な基準の一つに、カバレッジというものがあります。カバレッジとは、テスト対象のコードの中で、テストが行われた割合のことをいい、パーセントで表現します。カバレッジ率は、いくつかの基準で取得しますが、主に以下のような基準があります。

命令網羅(statement coverage):
コード内のすべての命令が少なくとも1回以上実行されたかどうかで判定する基準です。 分岐網羅(branch coverage):
コード内の判定分岐の結果として、真になる場合と偽になる場合の処理がそれぞれ1回以上実行されたかについて判定する基準です。 条件網羅(condition coverage):
コード内の判定条件のすべての真偽の組み合わせが実行されているかを判定する基準です。  これらの基準は、カバレッジを取得する基準という意味だけでなく、テスト設計の基準にすることもできます。プロダクトの特性やアーキテクチャの特性を考慮し、どの網羅率を重視するのかをチームで話しておきましょう。

 また、カバレッジは、プロダクトコードの中でテストがどれだけ通っているかは示してくれます。逆に通っていることしか示していないため、それぞれの基準がすべて満たされていれば、バグがないことを保証するということではありません。とはいえ、プロダクトコードやテストコードを眺めているだけでは当然どれだけ網羅されているかは分かりませんし、常に他のメンバーが書いたテストコードを読み続けていたら開発時間が足りなくなります(もちろん、時として読む必要がありますが)。そこで、カバレッジをコードの状態を「見える化」する手段の一つとして利用するのです。

 つまり、カバレッジは、絶対的な品質を保証する値ではなく、1つの指標としてコードの状態やテストがどこまで書かれているかや、漏れはないかなどを見える化するための手段だと考える必要があります。

■カバレッジを見える化し活用する

 カバレッジを見える化しても、誰にも見られないと意味がありません。誰も見ないデータは無駄です。では、どのようにしてチーム内でカバレッジを有効活用していけば良いのでしょうか。筆者の関わったテストコードがまったくなかったチームを例にお話したいと思います。

 カバレッジをチームで活用するためのプロセスは大きく分けて3つあります

図1 カバレッジを活用する3つのプロセス


●1)「自動化」現状のカバレッジがいつでも見える

 データは見たいときに見えるようにしないとチームのメンバーは見ません。面倒な手順を行わないと見えないなどという状態だと、そのプロセスすら面倒になり誰も見ません。そこで、カバレッジを取得する場合は必ず自動化しましょう。常に最新ソースをビルドをしている状態を継続的インテグレーションの環境と共に作成し、ビルドと同時に自動テストとカバレッジの測定をするようにしましょう。

●2)「グラフ化」カバレッジの変化が見える

 毎日のカバレッジ率の変化をグラフ化するようにしましょう。変化をグラフ化すると、自分たちの成果が目に見えます。グラフが上に上がっていく(カバレッジ率が上がっていく)と嬉しい気持ちになります。少し手間ですが、Excelでも紙でもいいので、チームの中に係を決めて書いていってください。書いた上で、例えば毎朝の朝会のような場で状況をチーム全員で状況を確認できるようにしましょう。

●3)「タスク化」コードに反映する

 実際にテストコードをチームが書くためには、「時間があったら書こう」のようなあいまいな状態ではなかなか書きません。プロダクトコードを書くのであれば必ずテストを書くというルールが適用できないチームであれば、できる範囲で良いので、必ずタスク化しましょう。タスク化することで、チームメンバーは書かざるを得なくなります。またその成果が1)2)のように目に見えるようであれば、よりその気持ちは強くなります。

 この1)~3)の毎日の繰り返しが、テストコードを書くモチベーションになっていきます。自分たちのやったことが見える化され、その変化も一目瞭然で見える。その結果からさらにテストを書いていく。このフィードバックループが回すことが大切です。

 この方法は、テストコードが書かれていないチームに対して特に有効です。もちろん、行う前にテストコードを書く有用性をしっかり説明する必要がありますが、筆者の経験ではテストを書くこと自体を反対する人はなかなかいません。もしいたとしても、それは時間が足らないなどテストコードを書くこと以外の理由のほうが多いです。その問題に対しては、できるだけチームで解決したり、できることからやれる環境を整える必要はあります。

 このような見える化とフィードバックループの関係は、チーム開発ではカバレッジに限らず有効です。ぜひやってみてください。



CodeZine

トピックスRSS

ランキング