#topicpath ---- [[クライアントサイドのjcoverage>Java/jcoverage]]に関しては何とか動いたようです。いよいよサーバサイドのカバレッジ計測をやってみようと思います。確認は以下のような環境で行いました。 |BGCOLOR(#CCFFFF):LEFT:プロダクト|BGCOLOR(#CCFFFF):LEFT:バージョン|BGCOLOR(#CCFFFF):LEFT:役割| |LEFT:WebSphere|LEFT:WebSphere 5.0.2テスト環境((Studioについてくるヤツ))|LEFT:WEBコンテナ| |LEFT:Cactus|LEFT:1.7.1|LEFT:サーバサイドテスティングフレームワーク| |LEFT:Junit|LEFT:3.8.1|LEFT:テスティングフレームワーク| |LEFT:jcoverage|LEFT:1.0.5|LEFT:カバレッジツール| [[Cactus>Java/Cactus]]とはサーバサイドのテスティングフレームワークです。JUnitのクラスを拡張して、WEBコンテナ上でテストを行うためのクラス群を提供します。 具体的には、requestパラメータにいろいろな値をセットしてブラウザのリクエストをシミュレーションすることや、ブラウザへ返却される画面に正しく値がセットされてるかをチェックするクラスなどを提供してくれます。 さて、[[前回>Java/jcoverage]]にJUnitとの連携まではやりましたが、今回がいままでと違うところは''WEBコンテナ上で稼働する箇所とクライアントで稼働する箇所がある''というところです。つまりリクエスト情報を構築してリクエストを放るまではクライアント側のJavaVM,リクエストを受けて処理をしてクライアントに返すまではWEBコンテナ上のJavaVM、という方式になります。クライアント側のカバレッジ計測についてはある意味いままでと変わらないのですが、WEBコンテナで稼働する部分のカバレッジ計測をどうするかというところがポイントになります。いろいろ調べた結果、以下のようなやり方でやればよい(ような気がする)事がわかりました。 -クライアント側はクライアント側で、コンテナ側はコンテナ側でそれぞれ計測して、マージする -計測するにはデバッグ埋め込み済みのコードをデプロイする必要がある -(特にWASだけかも?)WEBコンテナにjcoverageのjarをパスを通して認識させておく 難しいのは、デプロイするearにアーカイブされるクラスにどのようにデバッグを埋め込むか、ですね。通常開発環境でのコーディング・テストフェーズでは、自分でアーカイブを作ることはせず、開発環境が勝手にデプロイしてくれることが多いからです((WebSphereなどに限らず、最近の環境はどこでもそうですよね))。これに関してはclassesにデバッグ埋め込み済みのコードを配置するようビルドする、ことで解決できそうです。 さて例でやってみます。 ***準備 [#g4459cec] ***手順 [#oa26c415] 手順は、Eclipseでコンパイル -> AntでInstrument -> WEBコンテナ起動 -> EclipseでCactus起動 -> Antでレポート となります。ポイントは -デフォルトではclassesがクラスパスに設定されてしまうので、instrumentしたファイルがclassesに配置されるようビルドする って事です。 ---- この記事は #vote(おもしろかった,そうでもない) #comment #topicpath SIZE(10){現在のアクセス:&counter;}