SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

JavaScriptでテストを書こう!

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

JavaScriptでテストを書こう! 第6回

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

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

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

対象読者

  • JavaScriptの基本をある程度理解している方
  • テストコードをこれから書こうと考えている方

カバレッジとは

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

  • 命令網羅(statement coverage)
    コード内のすべての命令が少なくとも1回以上実行されたかどうかで判定する基準です。
  • 分岐網羅(branch coverage)
    コード内の判定分岐の結果として、真になる場合と偽になる場合の処理がそれぞれ1回以上実行されたかについて判定する基準です。
  • 条件網羅(condition coverage)
    コード内の判定条件のすべての真偽の組み合わせが実行されているかを判定する基準です。

 これらの基準は、カバレッジを取得する基準という意味だけでなく、テスト設計の基準にすることもできます。プロダクトの特性やアーキテクチャの特性を考慮し、どの網羅率を重視するのかをチームで話しておきましょう。

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

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

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

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

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

図1 カバレッジを活用する3つのプロセス
図1 カバレッジを活用する3つのプロセス
1)「自動化」現状のカバレッジがいつでも見える

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

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

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

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

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

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

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

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

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
JSCoverでカバレッジを取得する

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
JavaScriptでテストを書こう!連載記事一覧

もっと読む

この記事の著者

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

WINGSプロジェクト 安西剛 (ヤスニシ ツヨシ)

WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS Twitter: @yyamada(公式)、@yyamada/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/8022 2014/09/19 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング