2013年4月25日木曜日

コードカバレッジにテストケース分も含むべきか?

JaCoCO Maven Pluginでテストケースのカバレッジもとるの後、パッチを書いてpull requestを出しました。
結論から言うと、一旦取り下げました。

作ったパッチは、

  • mavenでJUnitのテストを実行した際に、テストのオブジェクトファイルができる場所(例えばtest-classes)をカバレッジ対象に加える

というものです。前のブログで書いたような結果が得られます。
しかし、以下のような点からデフォルトで含むのはどうなの?という意見がでました。

  1. あまりコードカバレッジにテストケース分を含むのは一般的じゃないんじゃない?
  2. だって、プロダクションコードのカバレッジと混ざって、ほんとのカバレッジが見づらくなるじゃん?
  3. EclipseのプラグインであるEclEMMAの場合は、テストコードの場所に決まりが無いから全部にしてるんだよね。
    #やばい、closeした時、誤訳してたと書いてて気づいた。。。
  4. 少なくともデフォルトは出さない方がいいよね。

1は、普通フォルダだったりパッケージだったりを分けるんじゃないかな?と思います。
カバレッジもそれぞれで分けて表示できると思うので、問題にならないんじゃないかな、と。
2は、1のように分けていなければ、その通りだと思います。

そもそもパッチを書いた理由は、テストケースのカバレッジも見えるべきじゃない?ということでした。
他の意見としても、デフォルトは出さずオプションで選択できるようにしたらいいんじゃない?というものでした。
Maven pluginの形をとるという事は、いろんなケースがありえる前提に立って2のようなことを避ける方に倒すべきかな、と考え直し取り下げました。
オプション形式に書き直そうと思ってます。

で、JaCoCo Maven Pluginではパッケージで階層化されたレポート出力になるので、混ざらないように書いておくのが良いのかな?
ベストプラクティスとかあるんですかね?

0 件のコメント:

コメントを投稿

RedmineプラグインをGitHub Actionsでテストする

Redmine Advent Calendar 2019 の Qiita で書きました。追っかけで もう一つ 。 Travis-CIで行っていたRedmineプラグインのCIを、GitHub Actionsに変更したものです。 GitHub Actionsをやってみようという...