私はあなたの問題を理解していますが、個人的には、のデフォルトの動作を変更するオプションがあることはそれほど有用ではないと思いますF9。
例外を発生させることが予想されるいくつかのテストケースがあります。（注：私は実際に、不正な入力が与えられたときに特定の例外をチェックするテストを考えています。例外はアプリケーションによって「処理」されません。）そして、ほとんどの状況でこれらに警告される意味がないことに同意します。ただし、他のテストケースの例外は、できるだけ早くアラートを受け取りたい問題です。
したがって、私の好みの実行モードは、通常、例外が通知されることです。また、特定のテストケースに、本番コードの例外をトリガーするテストのコンテキスト内でのみ例外通知を明示的に無効にする明示的なコードを用意します。
私はこれに非常にうまく機能するテクニックを持っています。
例外が発生すると予想されるテストでは、次のコードを記述します。
begin
TIDEDebugTools.DisableBreakOnExceptions;
try
//Test code ...
finally
TIDEDebugTools.EnableBreakOnExceptions;
end;
end;
これら2つのメソッドのソースコードが必要だと思いますか？:)
unit IDEDebugTools;
interface
type
TIDEDebugTools = class(TObject)
public
class procedure DisableBreakOnExceptions;
class procedure EnableBreakOnExceptions;
end;
implementation
{ TIDEDebugTools }
class procedure TIDEDebugTools.DisableBreakOnExceptions;
begin
end;
class procedure TIDEDebugTools.EnableBreakOnExceptions;
begin
end;
end.
あなたが尋ねる残りはどこにありますか？
何もありません-それだけです！
...しかし、従う必要のあるいくつかの指示があります：
- 各メソッドにブレークポイントを追加します。
- ブレークポイントプロパティを編集します。
- 詳細オプションを選択します。
- 「ブレーク」オプションをオフにします
- そして、適切なそれぞれのメソッドの「後続の例外を無視する」および「後続の例外を処理する」オプションをオンにします。
これは、コンパイラ指令オプションに関するjpfolleniusの考え方に近いものです。また、これらの例外を再度有効にする方法に関するDavidの懸念にも対処します。ブレークポイントを無効にして、すべての例外が再度報告されるようにするだけです。
追加の考え：
あなたが言及する：
一部のテストコードは、アプリケーションによって処理される例外を生成します。
アプリケーションがこれらすべての例外を処理している場合は、次のようになります。
- テストは十分にローカライズされていますか？このような大きな機能のチャンクをテストしている場合、テストはシステムテストに似ており、保守が非常に困難になる可能性があります。
- メインラインのビジネス処理で例外を使いすぎていませんか？
- アプリケーションは不適切な例外を大量に飲み込んでいますか？
基本的に、あなたの言葉遣いが「処理されているのであまり気にしない例外の束」を示唆しているのは私には怪しいようです。多くの人は、実際には例外を飲み込んで根本的な問題を隠しているだけなのに、例外を処理していると誤解しています。
