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

2013年4月21日日曜日

JaCoCO Maven Pluginでテストケースのカバレッジもとる

JaCoCoというJavaのカバレッジライブラリを調べています。

テストコードを書いて確認。EclipseのプラグインであるEclEMMAは内部でJaCoCoを使っています。
とりあえずオールグリーンです。


カバレッジが100%ではないですが、ここでは問題にしません。#ほんとはこれを調べてたんですが。
ちゃんとテストコードのカバレッジもとれてます。


次にMaven Pluginです。使ったバージョンは、0.6.3-SNAPSHOT。
HTML、XML、CSVでレポートが出力されます。HTMLのレポートを開いたものです。テストコードのカバレッジが無いです。


調べていくと、prepare-agentゴールでデータを作って、reportゴールでレポート化しています。
prepare-agentゴールでは、JavaAgentを使ってデータを取っています。この辺はたぶんEclEMMAも一緒のはず。
実際、HTMLレポートのSessionsのリンクをたどると、実行時のデータがすべて出てます。


ここを見るとちゃんとテストコードも通ってます。ということは、データは取れているけどレポートできてない、EclEMMAで出てるという事は、Maven Pluginで出ていないですね。


で、いろいろとpomをいじってみましたが駄目だったのでソースをみることに。
https://github.com/two-pack/jacoco/blob/master/jacoco-maven-plugin/src/org/jacoco/maven/BundleCreator.java
 public IBundleCoverage createBundle(
   final ExecutionDataStore executionDataStore) throws IOException {
  final CoverageBuilder builder = new CoverageBuilder();
  final Analyzer analyzer = new Analyzer(executionDataStore, builder);
  final File classesDir = new File(this.project.getBuild()
    .getOutputDirectory());

  @SuppressWarnings("unchecked")
  final List<File> filesToAnalyze = FileUtils.getFiles(classesDir,
    fileFilter.getIncludes(), fileFilter.getExcludes());

  for (final File file : filesToAnalyze) {
   analyzer.analyzeAll(file);
  }

  return builder.getBundle(this.project.getName());
 }

classesDirがgetOutputDirectory()になってます。target/classesだけみたい。。。
ということは、target/test-classesも入れれば良いってことかな?
 @SuppressWarnings("unchecked")
 public IBundleCoverage createBundle(
   final ExecutionDataStore executionDataStore) throws IOException {
  final CoverageBuilder builder = new CoverageBuilder();
  final Analyzer analyzer = new Analyzer(executionDataStore, builder);
  final File classesDir = new File(this.project.getBuild()
    .getOutputDirectory());
  final File testClassesDir = new File(this.project.getBuild()
    .getTestOutputDirectory());

  final List filesToAnalyze = FileUtils.getFiles(classesDir,
    fileFilter.getIncludes(), fileFilter.getExcludes());
  filesToAnalyze.addAll(FileUtils.getFiles(testClassesDir,
    fileFilter.getIncludes(), fileFilter.getExcludes()));

  for (final File file : filesToAnalyze) {
   analyzer.analyzeAll(file);
  }

  return builder.getBundle(this.project.getName());
 }

ということでビルドして入れてレポート出した見た結果がこちら。ちゃんと出ました。


テストコードのカバレッジってデフォルトで出た方が、テストが思いがけず通ってない場合が見れていいと思うんですが、どうですかね?
フラグとテスト作ってリクエストしてみようかな。

2013年4月9日火曜日

長岡 IT開発者 勉強会(NDS) 第31回勉強会に参加しました。 #nds31

長岡 IT開発者 勉強会(NDS) 第31回勉強会に参加しました。
NDS自体初めての参加でしたが、とても楽しむ事ができました。
http://nagaoka.techtalk.jp/no31

テーマは「はじめての~」。初心者向けのテーマでなにか話して!ということでした。
以下、発表のまとめというよりも、気になったところの備忘録。発表順です。
スライドなど最新は上のページでまとまってます。

第31回勉強会 アジェンダ(@civicさん)

はじめてNDSに参加されたかたも多かったとの事で、@civicさんからNDSについての説明がありました。
誰にでも発表の場を提供します!、というのは、新潟において貴重な場ではないかと感じました。

はじめてのChrome App (@civicさん)

Chromeアプリでデバイスなどの低いレイヤーのAPIもあるということでした。
実際にUDPでメッセージを受けるデモをされてました。
bluetoothとかもあったので、今後何かやっていたいと思いました。

はじめてのmac用ビューアアプリ(@piras4さん)

最近はMBAべったりなのにXCode使ってみたこともない、、、、という私にはぴったりでした。
こんな風にするんだ、という感じでした。

はじめてのテスト技法 (@two_pack)

NDSの実施ポリシーが非常にいいね!と思い、NDS初参加でしたが私も発表してきました。
http://nagaoka.techtalk.jp/Home
中身はテスト技法の話はしておらずw、「ソフトウェアテスト」に触れるきっかけになれればいいなということで書きました。
初めてSlideshareにも載せてみました。100viewいくとメールが来るんですねw

はじめてのPerl(のモダン?な環境構築) (@hajyajoさん)

Perlの開発環境についてでした。システムPerlという言葉を初めて知りましたorz
開発環境用にバージョンを入れ替えるとか、ライブラリを指定のところに入れるとか、rvmみたいのか、と聞いていました。
IDEもあるようですw

はじめてのWindowsストアアプリ (@AILightさん)

生MVPだよ!生Surfaceだよ!と思ってたのは秘密ですw
ちょうど前の日に8のアプリを少し見たのもあって、非常に興味深かったです。
8がないのが痛いですが、やってみたいなあ、と思いました。

新潟スピリチュアル専科・または恋は言ってみりゃアウトプット (@neko_gata_sさん)

いきなりCoooolな音楽から始まりました!
新人教育で使いたいと思うし、うんうんとうなる、非常に良い話でした。楽しいって大事ですよね!
waveずたずたは原曲が気になるレベルのアウトプットでした。
プロセスさんには、ぜひpullRequestできるように読み込んでみたいです。

はじめてのメタプログラミング (@neko_gata_sさん)

メタな話でした。
ちょうどRubyGemのrequireでそんなのみたところだったので、Perlだとあんな感じでできるのか、と聞いてました。

わたしのRubyとの出会い (@kasacchifulさん)

@kasacchifulさんは、すわにいでもご一緒している方なんですが、ruby長いんだなあ、と今更w
Redmineのプラグインみてるのに、しっかり勉強してない、ってところを痛感したので、お勧めの本を読もうと思います。

懇親会

開発者で飲むってこういうのだよね、って感じですごく楽しかったです。
ただ、ちょっと楽しみ過ぎたのが玉にきずでした。。。 #おかげでこれ書くのも遅くなってる。。。

その他
そして、名刺のgithubとbitbucketのURLが逆になっているという@neko_gata_sさんからの指摘に愕然としましたorz
テストの話しておいて、このバグ。。。。

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

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