Debug.Assertとは

Debug.Assertは、想定している値や式を引数として書いておき、想定通りにならなかったときにマクロの実行を中断させるための仕組みです。

このDebug.Assertをパッと利用できるようになると、テスト駆動の考え方や関数作成後のテストにとても役に立ちます。また、プログラミングにもかなり慣れている状況になっていると思います。

構文
Debug.Assert booleanexpression
booleanexpression：Boolean型のTrueかFalseになる式や値を指定します。式が複数ある場合はOR条件であっても全ての式が計算されます。

単純なコードであればこのようになります。実行するとDebug.Assertの引数がFalseのため、Debug.Assertの行でマクロの実行が中断します。

Debug.Assertの用途と使い方

Debug.Assertの用途は、「ここを通るときは、こういう条件のデータに限られる」ということを書いておき、そうでない想定外のデータが来た時にトラップに引っ掛ける目的で使います。

通常のエラーチェックに使うものではありませんし、そういう使い方は間違いです。

では実際にどういう場面で使うのがよいかという話ですが、関数内の処理を全て書き終わったあとにDebug.Assertを書くのではなく、処理を書き始める前にDebug.Assertを書く、という用途の方が使い勝手が良くなります。

例を挙げます。

「処理仕様：1から10までの数字を連続して出力する。ただし、2の倍数の場合は出力しない。」

このような処理仕様が事前に決まっている場合、「やってはいけないこと」がはっきりしている場合があります。上の処理仕様であれば「2の倍数は出力しない」という点です。これを最初にDebug.Assertで書いてしまいます。

この時点では処理仕様の1から10などの処理は書いていませんが、それで構いません。プログラムは仕様通りに動作するのは大事ですが、場合によってはそれ以上に「やってはいけないことは絶対にやらない」ということを優先されることも少なくありません。

このように「やってはいけないこと＝想定外のデータ」の内容を明確にすることがDebug.Assertの用途の１つになります。あとは処理仕様に従ってコーディングしていきます。「やってはいけないこと」の条件に一致しなければDebug.Assertの行で処理は止まりません。止まらなければ正しい処理になっているとみなせます。もし、Debug.Assertの行で処理が止まるのであれば、「If文の条件がおかしいのでは？」、などの気づきになります。

これは単純な処理仕様のため、先にAssertを書くことを恩恵が見えにくいですが、複数の条件が組み合わさっている場合や、状態遷移表を作成しないとよくわからないような条件の場合は恩恵が多大に発生します。

Debug.Assertを使うことで発見できるもので多いのが「条件間違い」と「処理の位置」です。上の例ではIf文の条件（i Mod 2 <> 0）がそれにあたります。

Debug.Assertは残したままでいい？

Debug.Assertはコンパイルしても引っかかりますが、プロジェクトのロックを行った場合は引っかからなくなります。ただ、プロジェクトのロックを行うことはあまり無い気がします。

Debug.Assertを残すかどうかですが、他の人に渡すマクロの場合だったり、関数作成時の検証の意味が強かったのであればDebug.Assertはコメントアウトしておく方がいいかもしれません。

でも、自分用のマクロなのであれば残しておく方がよいでしょう。仮にDebug.Assertに引っかかったらむしろバグが見つかってラッキーで自分がVBA画面でデバッグすればいいだけの話なので。

ちなみに、私はコメントアウトではなく物理的に消すことが多いです。Debug.Assertを使うような場合はその関数をテストするテストコードを書いていることのが多いため、っていうのが理由です。

なお、プロジェクトのロックを行うには、VBA画面で対象ブックのVBAProjectを右クリックして「VBAProjectのプロパティ」でプロジェクトプロパティダイアログを表示し、「保護」タブの「プロジェクトを表示用にロックする」にチェックを付けてパスワードを設定した上で保存します。