井芹です。
鈴木たかのりさん、中村＠ＳＥＩさん、鈴木＠名古屋さん、ありがとうございます。
まとめてのレス御容赦下さい。
鈴木たかのりさん：
> > ServletとJspのテストはどうすれば良いか迷いました。
> > 結局は、いつものように目視でのチェックになったのですが、普通は
> > どうすべきなのでしょうか？
> このあたりの「普通どうすべき」はみなさん模索されているところなのでしょ
> うか?私自身「簡単ですっきりする」方法というものは見つかっていません。
> みなさんはどのように試験していますか? < Servlet/JSP
やはり他にも苦労されている方がいらしたんですね。
少しほっとしました。
> > ServletはCuctusで出来そうですし、JspはHttpUnitで出来そうだとは
> > 思っていたのですが、HttpUnitは結果のHTML全てを確認できるような
> > ものでもなさそうですし、このHTMLが表示された際にJavaScriptが走る
> > ような場合はどう確認するのかわかりませんでした。
> Cuctusはいまだ導入できず...
> HttpUnitの試験も「ここ」に「このデータ」というようにチェックはできるの
> ですが、確に画面の全体的なチェックとかはできないですね。
そうなんです、最初は出来たページ自体が確認できるのかと思ったのですが、
実際はそうじゃなかったので、その時はあきらめました。
ただ、もう一度なんとか挑戦したいとは思っています。
> 実は、HttpUnitによるUnitTestは通っていたけど、文字が全部???とかに化け
> ていたということもありました。
>
> UnitTestだけを過信するというのも危険なのかなと反省しました。
なるほど。やはり目視確認も重要ですね。
UnitTestが通っても安心しないで、念のため早めに目視確認する必要があり
そうですね。ブラウザによって動作が変わることもありますし。
> > DBからデータを取得し、ファイルに出力するという処理なのですが、
：
> > 普通はどうするものなのでしょうか？
> こういう処理は確に面倒ですけど、できるだけ行っていました。
> setup(), teardown() メソッドでテスト用データの書き込み/消去などをして
> いました。
> 現在のデータの状態によってUnitTestが通らないのは気持悪いので、できるだ
> けそのようにしておきました。一回書けばいいだけなので、そんなに大変とい
> うこともないし、精神衛生上良いと思います。
なるほど、そうかもしれません。
次回はファイルから読み込んでDB更新という処理を作るのですが、
一度挑戦してみたいとおもいます。ただ、DBの構造が良く変わるので困るのですが。
> > ふっと思ったのですが、２人で開発する場合もペアプロするの
> > でしょうか？
> > 今のプロジェクトは二人なんです。
> 2人プロジェクトのときもペアプログラミングしていました。
> つまり、つねにその同じペアでプログラミングです。
メンバー交代が出来ないですし、喧嘩になりませんか？
中村＠ＳＥＩさん：
> 最初のテストは目視で、次回からは HTML の結果が同じであれば
> JavaScrpit も同じ動作をすると割り切っています。
>
> テストの際は、下記の点に注意が必要です。
>
> (1) 現在日付を扱う処理
> 当社の場合は、フッターに現在日付を表示していた為、毎回エラーとなり
>
> ました。
> また、日付の項目に現在日付をデフォルト表示する時もエラーとなります。
うちでも最初の結果をじっくり検証しておいて、２回目以降はそれと確認するという
ようにしようとしたのですが、おっしゃるようにどうしても日付に差異が出てしまうのと
その結果ファイルの管理が面倒な気がしたのでやめました。
> (2) ＤＢのデータ
> 当然のことですが、ＤＢの検索結果を表示している画面では、ＤＢのデータが
> 前回と同じである必要があります。検索→更新→検索という画面遷移のテスト
> では、再度データをロードする必要があります。
> Oracle シーケンス等の値も再設定する必要があります。
テストデータと、テスト項目書はExcelで作ったので、マクロを利用してこの辺も
問題なくスムーズにできるように心掛けました。日付の件もクリアしました。
完全ではないのですが、従来よりはかなり工数が稼げたので、次回も更にマクロを
洗練させて行こうとしています。半自動なので、機能テストだけですが。
> >DBからデータを取得し、ファイルに出力するという処理なのですが、
> >前処理でDBにデータを挿入するとか、後処理でファイルを読み込んで
> >検証するとかいうようなテストケースを書くのが普通なのだろうかと
：
> 当社では、データの自動生成ツールを作成して対応しています。
>
> 例えば、氏名のフィールドには、"1.氏名xxxxx" , "2.氏名xxxxx"...
> という値をセットします。参照制約も考慮しながらデータを生成します。
これは、テストデータ自体の生成ツールですか？
うちの場合は、フラグ的な項目が多かったので、データ自体はExcelのシートに
手入力しました。
ただ、そのデータの投入ツールはつくりました。
鈴木＠名古屋さん：
> 開発にJUnit, Cactusを使っています。
Cactusは使いたかったのですが、覚える工数がありませんでした・・・
> ServletもJSPもCactusを使っています。ModelはJUnitを使って、ViewとControler
>は
> Cactusと言う形にしています。
ViewもCactusで出来るのですか？
全然頭にありませんでした。
> しています。Cactusで行うJSPのテストも見た目でなく、JSP内にある、
> 処理の試験に用いています。文字化けについても、Cactusである程度
> まで試験できます。
なるほど、次回は是非とも試したいです。
> Cactusは導入するのに、結構時間がかかりました。オンラインドキュメントを
> かなり読み込んでやってみてもうまく動いてくれなくて、結局サンプルに
> ついてきた、build.xmlファイルを少しずつ書き換えていって、やっと自分達
> の試験に使えるようになりました。
根性いれて頑張りますです。
> >> DBからデータを取得し、ファイルに出力するという処理なのですが、
：
> >こういう処理は確に面倒ですけど、できるだけ行っていました。
> >setup(), teardown() メソッドでテスト用データの書き込み/消去などをして
> >いました。
>
> うちも同様に、setup(), teardown()を使って、テストデータのローディング
> や削除を行い、なるべくDBに入っているデータ状態に依存しないように試験を
> 行っています。
私が考え過ぎなのかもしれませんが、DB更新の場合はまっさらのデータでテスト
したほうがいいのかなと言う点でした。
データが更新された事の確認は簡単なのですが、更新されていない事の確認は
どうするのだろうと。
例えば、とんでもない部分が過って更新されている場合、全データを検証しない
と問題が見つからないような気がして。
ユニットテストの範疇ではないのかもしれませんが。
> Servlet や JSP から DB に接続する Bean を呼び出している場合は、どうしても
> 試験が遅くなってしまうので、Mock Object(http://www.mockobjects.com/)を
> 利用するようにしたいなと考えています。そうすれば、DB のデータに依存しない
> Servlet や JSP 内のテストは、できそうな気がしています。
良い事を教えて頂きました。参考にしたいです。
当面servlet関係の開発が続きそうですから。
> きれいに、テストが通った時は結構気持ちがいいですね(^^)
>
> テストが、1000ケース以上あるので、昼休みに自動で走らせています。昼休み後に
> Xalanが生成したレポートを見るのが結構楽しみです。
うーん、体験したいです。
XPのセミナーに行ってから更に「やりたい度」が増しています。
色々模索しているのですが、リーダーでもなくお客さんと交渉する立場でもない
ので、なかなか上手くいかないですね。
みなさん、ありがとうございました。
_/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_/
_/ 井芹 義博 (Iseri Yoshihiro)
_/ Mail: IseriY@....com
_/ URL : http://members.aol.com/iseriy/index.html
_/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_/