2012年06月16日

JSP/JSFでの項目をフォーマッティングするタグをできる限りやめてみる

JSPやJSFの魅力の一つにカスタムタグがあります。タイトルはこのカスタムタグを否定しています。
カスタムタグを利用することで、モデル層・コントロール層でいちいち画面に表示する内容を整形する必要はありません。これらは全てどのように表示するかをビュー層に任せることができ、MVC構造上分かりやすい(責任境界が明確)と言えます。

例えば仕様変更によって、画面上の日付をyyyyMMddからyy/MM/ddに変更する必要が発生した場合、カスタムタグ(これぐらいならJSPの標準タグでできそうですが)を用いれば、ビュー層まではDateやTimestamp型で送られてきているため修正は不要です。結果、JSPのその出力タグのどのように表示するかを指定する属性を変更するのみで、修正は終了です。

ポイントは、修正はこれで終了である、という点です。

テストはというと、画面を実際に表示する必要があります。
さて、ここでこのカスタムタグが十分にテストされていることを前提としている場合でも、本当に問題がないのかを確認するには、JSPを表示してみる必要があります。これで実はMMの部分が月ではなく、分を指定していたとしても、たまたま12分までの間にテストをしていたら、修正ミスに気付けません。よって、テストでは12分以上をしっかりと確認する必要があります。
現状の開発では、Seleniumを使わず結局目視で確認しています。また、目視でもしっかりとしたテストケースをあげているケースもレアです。こういう場合は、しっかりと最小桁、最大桁のテストとして、00と12はテストする必要があります。仕様をしっかり確認し、分のところの00は0になるのか00のままなのか、分になっていないのかを確認する必要があります。

さて、seleniumを使っていたとしても、仕様変更のためにシナリオを変更してここまで確認するのは面倒です。seleniumはやっぱり目視での確認後に、デグレが発生していないかを確認するためのものとして現場では利用されているのでしょうか?

弊社では、seleniumすら利用しようという空気はないため、目視1ケースのみで終了となり、同時に回帰テストは二度と行われません。
よくあるのが、ここで結局ミスをしていたというのも多発しています。


カスタムタグが十分にテストされているケースであればまだ良しと言えます。このカスタムタグが弊社自作の場合で、かつ、十分なテストが実施されていない場合は、このカスタムタグをテストしているのか分からない状況になることもあります。


最近のWebアプリケーションの見栄えはとてもよく、例えば長い文字列を表示する場合は、"..."と省略形に自動的になり、マウスを近づけるとチップ形式で全文が表示されます。
業務アプリケーションにおいては、技術が時代に取り残されているのもあります(枯れたものを好んでいると理解しておきましょう)が、業務では一覧性が重要視されるために、文字列が省略されることなど滅多にありません。
つまり、表示したい内容はまさに、そのまま書式化されたものを単純に表示すれば事足ります。


カスタムタグにあるような、書式を自由に変換できるタグは一切利用せず、これらは全てビュー層の前、ビジネスロジックで実施すべきです。そして、ビュー層ではその値がそのまま表示されるかどうかだけを確認します。

こうすることによって、ビュー層とビジネスロジック層のテストを分離しやすくしたいと考えています。

・ビュー層
ビュー層では、ビジネスロジック層のモックがフル桁および、最小桁のデータを渡すようにしておきます。
これがレイアウト上崩れないことを確認するのみのテストとすることで完結させます。
よって、ビュー層のみの単体テストを実施します。

・ビジネスロジック層
こちらはビュー層に渡すデータを出力として、JUnitでアサートするテストとなります。
つまり、日付であれば、テストケースとして正しくビュー層に表示すべき内容を変換してから渡しているか網羅的にテストすることとなります。こうすることによって、単純な書式の変更や変換の不具合の確認は、ビュー層で確認するよりもはるかに回帰テストしやすいものにできます。
ビジネスロジック層はそれ単体のみの単体テストを実施します。

・ビュー層とビジネスロジック層の橋渡しを行うBean
これはフレームワークにもよりますが、正しくビュー層・ビジネスロジック層で利用されているか、確認しやすいよう、それぞれ分かりやすい命名規約を用いることを推奨します。

・結合テスト
こちらはレイアウトや表示内容に関する網羅的な結合テストは実施しません。あくまで機能に特化したテストを実施し、ビューとビジネスロジックで正しい業務処理が行われるかの確認を行います。
ページ遷移はやむをえないでしょうが、フル桁はどうか、フォーマットはどうかなどの確認は不要です。そのままビジネスロジック層のデータが出ているかを確認します。
(当然、各項目ごとに値を変えて、出すべき変数名を間違えていないかを確認するのは言うまでもありません。こればかりはJSPやJSFでは確認しようがないでしょう。)


まとめると、私は、ビジネスロジック層で画面に表示する全項目の書式変換を行うべきだと考えています。


これはメリット・デメリット両方あります。
メリットは、Seleniumのシナリオで網羅性はあまり考えなくて良いでしょうし、JUnit/TestNGを利用するのでJenkins/Hudsonでバックグラウンドでテストさせておくと良いでしょう。また、カスタムタグだけでは表現しきれないものは、工数見合いで結局ビジネスロジック層に実装することが多いため、ビジネスロジックに集約することでライブラリ化が容易になります。

デメリットは、JSPの修正だけであれば、JSPを置き直すだけでリコンパイルされるのですが、ビジネスロジックを修正する場合はアプリケーションサーバーのホットデプロイか、サーバーの再起動が必要なのが面倒でしょう。
もとから変更はサーバーを止めてしっかり検証するでしょうが、緊急対応には向かないかもしれません。
posted by Kiruahさん at 18:09| Comment(0) | TrackBack(0) | ノウハウ
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/56518769
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック