netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2006-04-18 ▲
_ [ツール] テストからの擬似クラス生成 ▲
Java World のニュース欄でちょっとだけ話が載ってたので，JaSST のほうの原稿などを読んでみた．
伊尾木 将之，河野 広伸，合田 英二: TDDを加速する擬似クラス生成方法 - Simulated-Class by Tests with KikainekoMocker -．ソフトウェアテストシンポジウム 2006.
"Simulated-Class by Tests" という，テストケースを入力としてテストを通過する最小限の実装を生成する手法の提案．
予稿集では，手法ではなく使うことでどううれしくなるか（試行錯誤の容易化，コミュニケーションの容易化，設計の確認）がメインで，手法についての形式的な記述は特になし．
手法の実装であるKikainekoMocker公開サイトにある設計概要によると， テスト用コードをインタプリタとして実行し，メソッド呼び出し列を "TargetClass" に送信し， assert 文が来たところで「このメソッド列に対して出力はこうなるはずだ」という判断を下す，らしい． 抽象実行とかの一種と考えるとしても， Java コンパイラや実行系がやっていることと似たようなことをやろうとしているので， たぶんすごく実装には手間がかかっていると思われる．
このアプローチで大変そうな点は，まず１つ目として， モック生成対象クラスが存在していない段階で JUnit テストケースを書く都合上， そのテストケースは未知のクラスを参照したコードとなり， Eclipse 上などではエラーが発生してその他の意味エラーを検出できないかもしれないこと， ２点目は，戻り値が何らかの型に代入されていたり instanceof とかで判定されていたりしない限り メソッド戻り値の型が推論できないこと．
テストコードを分析して必要なインタフェースを勝手に書いてくれる，と思えば プロトタイピングの支援としては便利そうだし， 対象オブジェクトの満たすべき状態遷移（っぽいもの）もついでに 出してくれると色々使い道はありそうな気がする．
発想はとても面白いのだけれど，あらゆる種類の JUnit テストケースに隙なく対応しようとすると，実装がすごく大きくなりそうというのが怖いところ． 最終的に落としどころがどうなるかは今後見てみないと分からない． 解析系なことをやってる人間としては，「不完全な（クラスが足りない）情報を解析」というのがどう実現されるかは興味深いところ．
公開されている KikainekoMocker プラグインを， 手元の Eclipse 3.1.1 + JRE 1.5.0.06 にインストールしてみたけど， NullPointerException とか色々エラーを言われて動かなかったので， また折を見て試してみることにする．
_ [論文] SPLAT 2006 パネルディスカッションのメモ ▲
今さらながら少しだけメモを整理．
パネルディスカッションのお題はスケーラビリティだった．
効率面では，当然オーバーヘッドが少ないほうがいいに決まっているので，あまり変な話は出なかった．大規模システムでも低レベル（一番実装よりというか，テクニカル）な横断的関心事がたくさんあって大変だった，とかいった苦労話のようなことは少し出ていた．
アスペクトの利用法については，たとえばあるクラス群Ｃ，Ｄ，Ｅに貼りついているアスペクトＡがあってパッケージを構成しているとき，新登場したクラスＦにはアスペクトＡは実は貼りつくべきではないのではないか，また，外部に新しいアスペクトＢが出てきたときにそれはＣ，Ｄ，Ｅに影響を与えるべきではないのではないか，という話が出ていた．アスペクトの影響範囲（スコープ）をサブシステム内部とかある程度限定しないと，予期しないところでアスペクトが影響を与えてしまうかもしれないので，アスペクトの影響をうまく管理できるようにしたいね，という話にはわりとみんな同意していた．Erik Ernst は "safe applicability" というような言葉を使っていた．
_ kikaineko [KikainekoMockerの作者です。試してみていただきありがとうございます。 ご想像の通り、実装はかなり手間が..]
_ いしお [どうも，ご連絡ありがとうございます．また時間があれば，最新版をつついてみたいと思います． KikainekoMock..]