C#: best practice Debug.Print

Question

Qual è la migliore pratica relativa alle dichiarazioni Debug.Print?

Devo sporcare i miei metodi di classe con le dichiarazioni Debug.Print o dovrei evitare del tutto lo Debug.Print?

Se le dichiarazioni Debug.Print sono accettabili, dovrei considerare l'utilizzo di Trace.Print o EventLog?

Le istruzioni Debug.Print sono necessarie con le unit test? Posso evitare le dichiarazioni Debug.Print con test unitari ben scritti?

Answer 1

Debug.Print è accettabile, non ultimo perché verranno compilati nelle versioni di rilascio. "Littering" il tuo codice con esso, tuttavia, non sembra particolarmente produttivo o utile.

È possibile aggiungerlo durante il debug di una particolare area di codice. Una volta identificato il difetto, è possibile scrivere un test unitario per coprire il caso, correggere il bug e quindi rimuovere la chiamata a Debug.Print.

Quello che a volte uso e lasciare nella base di codice è Debug.Assert - è come un built-in punto di interruzione se la mia domanda non è in uno stato di attesa, che è solo una rete di sicurezza aggiunto mentre si fa sia automatizzato e test manuali .

Debug.Print non è necessario nei test di unità e non deve essere aggiunto per motivi di test dell'unità.

Answer 2

Non hai affatto bisogno di Debug.Print con i test delle unità! Il punto dei test unitari è che ottieni automaticamente un'indicazione sul fatto che il test sia riuscito o meno, non è necessario cercare stampe di debug per questo.

NUnit è una libreria di test dell'unità di facile utilizzo.

Per quanto riguarda la traccia o la registrazione, non è necessario sporcare il codice con le stampe di debug. Prova interception with Castle Windsor o altri framework che supportano AOP.

Answer 3

Non ho mai usato Debug.Print o Trace.Print. Scrivo una buona quantità di test unitari. Non ho mai trovato che ho bisogno di usare gli oggetti Debug o Trace con i test di unità che scrivo. Cerco di testare il più possibile, tuttavia.