Debug.Printステートメントに関するベストプラクティスは何ですか？C＃：ベストプラクティスDebug.Print
クラスメソッドをDebug.Print文で捨てるべきですか？Debug.Printを避けてください。
Trace.PrintまたはEventLogを使用してくださいと考えられる場合は、Debug.Printの文を使用できますか？
ユニットテストではDebug.Printのステートメントが必要ですか？よく書かれたユニットテストのDebug.Printステートメントを避けることはできますか？
Debug.Printは、リリースビルドでコンパイルされるためです。しかし、それを使ってあなたのコードを "うんざり"させることは、特に生産的で有用なものではありません。
特定のコード領域をデバッグするときに追加できます。欠陥を特定したら、ユニットテストを書いてケースをカバーし、バグを修正してから、Debug.Printへの呼び出しを取り除くことができます。
私が時々使用してコードベースに残すのはDebug.Assertです。私のアプリケーションが期待された状態にない場合は、組み込みのブレークポイントのようなものです。 。
Debug.Printは単体テストには不要であり、単体テストのために追加しないでください。
ユニットテストではDebug.Printはまったく必要ありません！単体テストのポイントは、テストが成功したか失敗したかを自動的に表示するので、デバッグプリントを探す必要はありません。
NUnitは、使いやすい単体テストライブラリです。
トレースまたはロギングでは、デバッグプリントでコードを捨てる必要はありません。 AOPをサポートするinterception with Castle Windsorまたはその他のフレームワークを試してください。
Debug.PrintまたはTrace.Printを使用したことはありません。私は単位テストの良い量を書く。私は、私が書いた単体テストでDebugオブジェクトまたはTraceオブジェクトを使う必要があることは決して見つけられませんでした。しかし、できるだけ単体テストを試みています。
「Debug.Assert」ステートメントも[リリースビルドで削除されました]（http://stackoverflow.com/a/13383661/1497596）。 （ 'DEBUG'がリリース設定に追加されていない限り）あなたのアサーションをリリースビルドで実行させたい場合は、代わりに[' Trace.Assert']（http://stackoverflow.com/a/6752696/1497596）を使用することを検討してください。 – DavidRR