coaraの日記： テストケースの作り方って 2
Tomcatで動かしてるWebアプリのテストプログラム（JUnitとかの）ってどう作ればいいんでしょ。
モック作るにしても必要な設定や前提情報が大量にあって手のつけようがない感じ。
初めからテストケース作りながらそれに合わせてコードを書いていればこんなことで悩むこともないんだろうけど、
10年近く色んな人の手によって拡張され大きくなった仕様書すらないソフトウェアじゃそんなことも言ってられない。
実際Tomcat+Struts+αなプログラムのテストプログラムは書いたことがある。
そこまで大きくないモックを作ってやれば簡単に試験できた。
さすがに小難しい条件や画面の遷移パターンは画面を表示しないといけなかったが、
画面に至るまでの機能を細かく分け各機能が他の機能の動作に依存しないようにしていたためテストケースは有効だった。
しかし今問題としているプログラムは色々な機能が密に依存しあい、どこから手を付けていいのか分からない。
モックを作る？一つのテストケースのモックを作るために最低でも1日は必要だ。というかそのモックの作り方が分からず一度挫折している。
そもそも各機能が依存しまくっていて、モックにしたい対象がどのような動きをしてどのようなアウトプットをしてくれるのかも分からないのだ。
できればもう、IDE上で「テスト実行！」すれば勝手にサーブレットコンテナが立ち上がってサービスを立ち上げて、
あとはテストケースでURLアクセスして画面遷移をシミュレートし、テストしたい画面の表示状態をその時に確認する…みたいなことができればいい。
画面の状態を目視確認するのは面倒だから、JSPが必要としてる情報をダンプしてくれるだけで結構。
裏では設定ファイルとかDBにアクセスしまくるだろうから、その設定ファイルの読み込み場所やDBの参照先もテスト用に弄れればなおよい。
バグ修正してjar作り直してサーバにアップロードしてTomcat再起動して画面を開いて必要な情報を入れないといけないような作業はもう限界だ…
レガシーコード改善ガイド (スコア:0)
レガシーコード改善ガイドを買ったまま積ん読だったことを思い出しました。
まあぶっちゃけると、諦めるしかないんじゃない？
テスト不可能なコードをテスト可能なように書き直すくらいなら、
いちから作り直した方が早かったりする。
あとはUIレベルのテストで我慢するくらいしか。
Re: (スコア:0)
古いコードでもやり方がある！のではなくもう諦めるしかないのね…
>レガシーコード改善ガイド
これ見て legacy program unit test でぐぐったら外人も「できんことはないけど途方もない労力がいる、でもやったほうがいい」みたいな感じでこれは…
ちょっと修正を加えるだけで予期しないバグの出てくるジェンガみたいなプログラムなので一から書き直すのも結構怖いんですよね。
幸いにもコードの変更に対しては寛容でいくらでも書き直していいって現場なので、数年間かける前提で直していくしかないっぽいですね