次第に腐るテストコード

結論を最初に書くと、
テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか?という事です。
最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。

「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。
なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テストコードは毎朝結果を確認しないといけないくらいセンシティブな生き物なのでしょう。

なので、テストコードを書いているから、「テスト自動化してます」なんて言ってたら微妙なのではないかと。そう。気づいた時にはリグレッションで動かないテストコードだらけ。あなたの周りに腐ったテストコードないですか?

と言う事で2011年初エントリ。みなさま、今年もよろしくお願い致します。

Hudsonに一目惚れ

CIをするための環境を調査。昔はCruiseControlとか、Continuousとか使っていましたが、かねがね噂を聞いていたHudsonを動かしてみた。今日TracHudsonPluginを見て動かそうと思ったんですけれども。これすごいですね。何がすごいって

  • ダウンロードしなくてもJava Web Startを使ってちょちょっと試せちゃう。
  • ダウンロードしてもこんなコマンド一個で動く
java -jar hudson.war
  • ちょっと試すだけだったらAPを立てずにすむ。
  • ブラウザからほとんど全ての操作ができてしまう。
  • 特にバッチとかも不要
  • crontab互換の記法を使って定時バッチを動かす事ができる
  • master/slave機能もついている
  • Tracとの統合(他にもあります)
  • プロジェクト名/buildとかで、指定しているビルドスクリプトを実行できる

特にwarなのに-jar指定で動かそうっていう発想は僕にはなかったです。良く考えてみたらJava Web StartEclipseもいけるんじゃないかと思ったけれども、100MB単位のサイズのアプリケーションだとダウンロードがつらそうです。

Eclipse Pluginのテストを自動化するには(その10:JUnit4でも自動化できた)

とりあえずコンソール上からJUnit4でテストコードを書いたテストプラグインの実行がうまく行ったのでメモ。

  1. バグレポート報告のページに添付されている『Eclipse Test Framework code』の方のパッチをEclipse3.3のテストフレームワークへpatch applyをする。
  2. テストプラグインのJUnitの指定を下記のように変更する
Require-Bundle: org.junit4
             ↓
Require-Bundle: org.junit;bundle-version=4

要するに指定するシンボル名を統一してバージョンを指定しるってこと。これはなぜかというと、今回当てるパッチはテストプラグインで指定しているJUnitのバージョンを見て、利用するプラグインを切り替える仕組みを採用しているためです。

Eclipse Pluginのテストを自動化するには(その9:JUnit4でも自動化する)

BugZillaを探したら、見つかりました。
https://bugs.eclipse.org/bugs/show_bug.cgi?id=153429

結構要望が多いらしく、パッチも作成されているので、それを使って環境を作成してみます。

Pluginのテストを自動化するには(その8:テストの自動化まででけた)

はい。一日かけて、さらに深夜におよぶ作業でしたが、なんとかテストの自動化まで終わらせることがでけました。事前調査によってJUnit4とリンクしたテストクラスが動作しないことが分かってたので、はまる時間が少し減ってよかった。(結局はまってはいたんですが。)
anonymousでもsvn exportで取得できるので、ご興味があれば。

https://eclipse-study.svn.sourceforge.net/svnroot/eclipse-study/PercsProject/trunk/org.kompiro.percs.releng/

JUnit4で作成したクラスを実行できないのは不便過ぎるので、それを解消すべくパッチを書こうかなと思ってます。その前にBugZillaを探せって言うとどもありますね。

Pluginのテストを自動化するには(その7番外編:ECFプロジェクトのCIプロジェクト)

ECF(Eclipse Communication Framework)プロジェクトではCIツールにCruiseControlが使われているということをこのプロジェクトで知りました。(これまでは噂で聞いたことがあったくらいです。)READMEがしっかりしていた点と、自分自身の備忘録をかねてどの辺にあったか、パスを書いておきます。

  • Host : dev.eclipse.org
  • Repository Path : /cvsroot/technology
  • Module : org.eclipse.ecf/builds
  • Tag : HEAD

残念ながらCI時にはテストはながしていない模様。

Pluginのテストを自動化するには(その7:拡張ロケーションを使ってデプロイする)

今回テストプラグインのデプロイをする方法を考えてみたんですが、直接テストをするためにEclipseのインストールロケーションにプラグインを展開するのはためらわれます。テストの初期化時に毎回100MB近いEclipseの配布ファイルを解凍し、テストプラグインをその中に放り込むのも考えたのですが、効率が悪過ぎでしょう。できれば拡張ロケーションを使えるのが一番よさそうです。プラグインの相性などもあるので、インストールロケーションへの配置をした上でテストをしないと意味がないという声もありそうですが、既にEclipseのサイトからは5種類に渡る配布があるわけですし、YoxosやらPulseやら自由にカスタマイズできる配布サイトもあります。要するに、インストールされているEclipseの状態は、特定できない訳です。

ちょっと前に拡張ロケーションを削除するには - Fly me to the Juno!という題で拡張ロケーションを手で削除する方法を書きました。今回は手で操作するのは無理があるので、方法を探しに探しました。結局見つけられたのはEclipseのHelpにも書かれている方法なのですが、なかなか見つけられなかったです。ところでドキュメントを検索するのって骨折れませんか?だったらソースから逆に辿って…。っていうのがいつものパターンです。特にJavaDocとかあってもなぁ。書いてある事は結局中見てみないと良く分からないことばっかだぉとか思うんですが、多分そういう人の方が少数派なんすかね。基本コメントを見なくてもわかるコードを書くのが信条です。

拡張ロケーションを追加するときはこんな感じのコマンドを打ちます。

eclipse -application org.eclipse.update.core.standaloneUpdate -consolelog -nosplash -command addSite -from /tmp/build/I.Build/eclipse

注意点は3点です。

  • eclipseランチャを使って起動しているので、javaやらstartup.jarを指定していません。後述するヘルプではその辺もきっちり指定していますが、素の必要はないです。
  • Windowsで、かつEclipse3.3以降を使っている場合はeclipsecランチャがあるので、そっちを使った方が幸せかもです。
  • -fromで指定しているパスが拡張ロケーションです。.eclipseextensionファイルを作るのを忘れずに。

逆に拡張ロケーションを削除する時はこんな感じのコマンドを打ってください。

eclipse -application org.eclipse.update.core.standaloneUpdate -consolelog -nosplash -command removeSite -to /tmp/build/I.Build/eclipse

その他この『org.eclipse.update.core.standaloneUpdate』というアプリケーションはインストールされているフィーチャーの一覧表示、フィーチャーのインストール、アンインストール、有効化、無効化など、『Manage Configuration』ダイアログでできる事が一通りできるようです。

参考にした拡張ロケーションやらフィーチャーをほげほげする時のヘルプです。
Eclipse 3.3の時の拡張ロケーションほげほげ
Eclipse 3.2の時の拡張ロケーションほげほげ