Java には 1.4からassert があって、これがなかなか良いものだけど、活用している現場をあまり見かけない。
MFC プログラマ出身者なら ASSERT マクロからの類推で、すぐに有り難味が分かるだろうけど、生粋の Java 現場では意外と知られていなかったりする。
普及しない理由として、javac コマンドに -source 1.4 を付けて、java コマンドに -ea を付ければ assert が効くという事を知っているだけでは、Eclipse 等の IDE 開発での場合にやり方が自明でなく導入しにくいという事もある気がする。
というわけで、以下、Eclipse 上で JUnit と Webアプリとして実行するときの、ちょっとしたTips。
====
Foo というクラスの execute() メソッドを不用意に呼んでしまったというシナリオで、コード的には、以下のように常に assert 失敗するようにした。public class Foo { public String execute() { assert false: "assertion test"; ・・・
◆ JUnit の場合
[Run Configurations...]から、[VM arguments] に-eaを指定する。設定は一度だけでOK。 実行すると、AssertionError の発生がちゃんと JUnit ビューに表示される。
◆ Web アプリの場合
下図のように[Run Configurations...]から、[VM arguments] に -ea を追加で指定する。 実行すると、ちゃんと AssertionError が上がってきて、Console ビューにスタックトレースされたのが見える。(ただし Servlet で AssertionError をもみ消してしまうコードがあると、当然あまり効果が無いので、そこは要注意。)
こんな感じで、開発中は常時 -ea を効かせておくようにすると、デグレ止めのセーフティネットとして役に立つ。特に人の出入りがあるプロジェクトで有効。もちろん、JUnit との併用が望ましい。
普及しない理由の残りは、どういう基準で assertion を書けばいいのか分からないという事もあるかもしれない。これは分かる人だけが assertion を書けばいいという方針で、おそらく十分。無理にガイドラインを作ってチームに強制するのは、費用対効果が余り良くない。
他の開発メンバに守ってもらうのは、ユニットテストやアプリの実行時に必ず -ea オプションを効かせてもらうという一点だけで良い。各自のコードが 既存の assertion に抵触した場合に、即座に分かるようなればそれだけで効果的だし、有用性が分かれば他のメンバも assertion を書くように、だんだんなってくる。
0 件のコメント:
コメントを投稿