プログラミング

プログラミング

【ちゃんとテスト出来てる?】テストカバレッジツールの落とし穴 

DevelopIntelligence

Your strategic goals won’t accomplish themselves. That’s where we come in. How many developers have you lost to competitors over the past few years? One? Two? Twenty? Are your projects experiencing roadblocks due to aging technology? How are your recruiting efforts? Are you struggling to find top talent – and to convince them to choose you? How much are you spending on training? Do you see any returns on that investment – or do your developers complain about time wasted learning the wrong things? We can fix all of that

本記事は、Why You Need Test Coverage, But Shouldn’t Trust It
翻訳・再構成したものです。
配信元または著者の許可を得て配信しています。

292 views

ユニットテストを含むあらゆるテストが役に立たないと誰かが言っているのを聞いたことは今まで一度もありません。実際、ソフトウェアのテストを行うのは良い考えだということに誰もが同意しています。テスト環境を整備してテストの作成にかかる時間については異論がありますが、とりあえずこれらの作業は終わっているものとして、今実際にテストを書いていると仮定しましょう。必要なすべてのケースをテストしたかどうかをどのようにして調べたら用よいのでしょうか。コードの一部にテストされない部分がある場合には、そのテストは役に立ちません。そこでこの記事のトピック、すなわちテストカバレッジが問題となるのです。

 

 

 

テストカバレッジとは何だろう

 

おそらくすべてのプログラミング言語には、それに適したツールがあるのでしょうが、今回はテストと並行して実行され、テスト中に実行されているコードを追跡できるJavaScriptに焦点を当てます。その仕組みについて私に尋ねることは遠慮してください。私に言わせてみれば、それはすべて魔法のようなものですが、ソースマップが手に入る限り、コンパイルされた、あるいは変換されたコードでも動作します。これらのツールのほとんどは、どのライン、ステートメント、およびコードブランチが実行されたかに関する統計分析結果を提供できるため、プロジェクトのどの部分がより多くのテストを必要とするかについて知ることができます。

 

テストカバレッジツールをコードのテストに統合するにはどこから始めればようのでしょうか。 JestというユニットテストフレームワークやVue CLIのようなスキャフォールディングツールなどを使用する場合には、コードカバレッジツールはあらかじめ組み込まれているため、ユニットテストのためにコードカバレッジを有効にするために余分な作業をする必要はありません。それとは別に、Istanbul、Blanket.js、JSCoverなどの一般的なテストカバレッジツールを使用することもできます。また、Sealightsのような単なるテストカバレッジツールを超えたものもあります。これは、時間の経過とともにカバレッジに関する統計を収集し、他にも企業向けレベルの機能を提供してくれます。しかし、そのためには費用がかかりますので、極めて高度なものを探している場合を除いて、無料のオープンソースプロジェクトを選択したほうがよいでしょう。ツールのインストール方法を知るには、個々のプロジェクトのサイトの説明をチェックする必要があります。

 

 

 

 

テストカバレッジにまつわる問題

 

多くの人にとってテストカバレッジツールを使用することは不可欠であると考えられますが、その際に注意しなければならないことがあります。カバレッジは、何らかの部分がカバーされていることを伝えるだけで、それは物語の終わりではありません。カバレッジは、単にどのコードが実行されたかを通知するだけで、コードが正しい結果を返したかどうかを十分にテストしているかどうかは分からないのです。

 

 

カバレッジが誤解を招く可能性があるいくつかの状況を次に示します。 

 

<span class=”hljs-keyword”>if</span> (a || b) {

foo()

} <span class=”hljs-keyword”>else</span> {

bar()

}

この例では、aがtrueで、bがfalseの場合とaとbの両方がfalseである場合のテストを実行すると、このコードの100%をカバーしたという結果が返されます。しかし、bがtrue、aがfalseの場合はテストしていません。この問題の重要性はコードによって異なるかもしれませんが、予期しない副作用がないことを確認するために、多くのケースをテストすることが大切です。

 

 

 

別の例を見てみましょう

 

eventEmitter.subscribe(<span class=”hljs-string”>’event'</span>, () =&gt; foo(<span class=”hljs-string”>’event'</span>))

<span class=”hljs-comment”>// … more code …</span>

eventEmitter.trigger(<span class=”hljs-string”>’event'</span>)

 

このコードがテストされた場合、カバレッジツールはコード全体がカバーされたと報告しますが、そのイベントリスナーの実行から正しい効果が得られていることをテストしないと、完全にテストしたことにはなりません。

 

 

結論

 

完全には正確な情報を提供してくれないテストカバレッジツールをそれでも使い続ける必要はあるのでしょうか。答えはイエスです。テストカバレッジツールは、厳密にはそうではない場合にもテストが完了したと報告するかもしれません。しかし、カバーされていないコードがあることをツールが検出した場合には、コードの一部が本当にカバーされておらず、そしてその部分をカバーするためのテストを作成する方法が明らかになるでしょう。テストカバレッジルーツは、場合によっては間違った信頼感を感じさせることもありますが、非常に便利です。言い換えれば、テストカバレッジをチェックしていないなら、これをすることがあなたの最優先事項である可能性があります。

 

 

 

 

※本記事は、Why You Need Test Coverage, But Shouldn’t Trust Itを翻訳・再構成したものです。

 

 

▼こちらの記事もおすすめです!

 

おすすめ新着記事

おすすめタグ