nDiki : 事後条件

assertion

昼食の時に話題になったので、考えてみた。

assertion を書いているか? いつ書くか?

最初からあまり書くことはない。 大抵、デバッグ中に書く。

ただし assertion を埋め込むようなデバッグをした次のコーディングフェーズでは、結構書く(長続きはしない)。

契約による設計をしたいと思いつつ、場当たり的。

C++ の時

最初に、自前の assert 処理を定義する(assert 関連マクロ、例外クラス、assertion を評価する関数など)。

比較的 assertion を埋め込む。

Java の時

うーん。C++ の時ほどは書かないかな。

 assert a_obj != null;

とか書いていて後で「あまり意味ないな」って思ったり。 C++ だと assertiion でチェックしておかないと発見が遅れる場合があるが、Java だと NullPointerException が吐かれるから大抵気がつくから。

• Java の assertion

Perl の時

簡単に無効化できないという意識があるためほとんど書かない。 大規模なパッケージの場合は、Makefile.PL を実行する際デバッグフラグを立てると make 時にコメントアウトされている assertion を有効にするようにソースコードを書き換える。

assertion を書くのをためらう時

• assertion の条件式の計算がヘビーな時
• assertion でチェックする条件の値を求めるのが面倒な時(ループを回さなければならないとか)
• 本来のコードより assertion の方がずっと多くてコードが読みにくくなる場合
• return 文が複数ある時(事後条件)
• 他のメソッドの戻り値を直接 return してしまう時(事後条件)

契約による設計と状態遷移モデルの抽出とか

事前条件/事後条件/不変表明で宣言できる仕様はプログラムの仕様の一部であるので、カバーできる範囲を明確にしつつ議論するのが重要。

テストフェーズとの連携

assertion による実行時検出の場合は、実際にそこを制御が通過しなければならない。テストフェーズとの連携があると実用的(単体テストスケルトンの自動生成など)。

表明状態数

事前条件/事後条件/不変表明から内在的な表明状態を抽出できたとして、状態数はどれぐらいになるのだろう? 1〜3ぐらいだと面白くない。かといって多すぎる場合は設計上の誤りがある可能性が高い。

過去の話題

• nDiki: assertion