前回の記事「MyBatis/iBatisの同値検証、sqlmapファイル（動的SQL）自体を単体テストする方法」で同値検証の方法は説明しましたが、既存バグもそのまま引き継ぎますね、ということでバグが何に起因するのか整理しました。今回は単なるポエムになります。
下の２つ「変換NG」、「出力SQL 同値NG」はiBatisからMyBatisへの変換作業におけるプロセスの問題です。iBatisのSqlMapファイルのタグには属性によってオプショナルな動作を制御するものがあります。タグの使われ方を調査し、そのプロジェクトにおける使われ方のパターンを整理すれば対応できます。また、調査をするとたまに現行のコーディング規約に沿っていないものが発見されたりもします。
問題は真ん中の「出力SQL 構文NG」です。現行で利用しているiBatisのSqlMapファイルなので、これはまずいのですが、動的SQLが複雑（SQL自体がとても大きい、入れ子の階層が深い等）であったりすると、テストをしていないということが発覚したりします。
論理的に説明すればどこにバグの原因があるのか明確です。既存ソースコードの変換（マイグレーション）は大規模システムではWillと需要がある分野ですが、既存ソースコードの品質がしっかり担保されていることが前提です。完璧なマイグレーションとは、ある意味、バグも含めて現行仕様を踏襲していると言えるかも知れませんね。