C#: prácticas recomendadas Debug.Print

Question

¿Cuál es la mejor práctica con respecto a las declaraciones Debug.Print?

¿Debo ensuciar mis métodos de clase con Debug.Print declaraciones o debo evitar Debug.Print en total?

Si las declaraciones Debug.Print son aceptables, ¿debo considerar usar Trace.Print o EventLog?

¿Se necesitan declaraciones Debug.Print con las pruebas unitarias? ¿Puedo evitar las declaraciones Debug.Print con pruebas de unidades bien redactadas?

Answer 1

Debug.Print es aceptable, sobre todo porque se compilarán en las compilaciones de lanzamiento. Sin embargo, "tirar basura" a su código con él no suena especialmente productivo o útil.

Puede agregarlo mientras depura un área de código en particular. Una vez que identifique el defecto, puede escribir una prueba unitaria para cubrir el caso, corregir el error y luego eliminar la llamada al Debug.Print.

Lo que a veces uso y dejo en la base de código es Debug.Assert - es como un punto de interrupción incorporado si mi aplicación no está en un estado esperado, que es solo una red de seguridad adicional al realizar pruebas automáticas y manuales .

Debug.Print no es necesario en las pruebas unitarias, y no debe agregarse por el bien de las pruebas unitarias.

Answer 2

No necesita depuración. ¡Imprima en absoluto con pruebas unitarias! El objetivo de las pruebas unitarias es que usted obtenga automáticamente una indicación de si la prueba tuvo éxito o no, por lo que no necesita buscar impresiones de depuración.

NUnit es una biblioteca de pruebas unitarias fácil de usar.

En cuanto a rastreo o registro, no necesita ensuciar su código con impresiones de depuración para eso tampoco. Pruebe interception with Castle Windsor u otros marcos compatibles con AOP.

Answer 3

Nunca he usado Debug.Print o Trace.Print. Escribo una buena cantidad de pruebas unitarias. Nunca he descubierto que necesito usar los objetos Debug o Trace con las pruebas unitarias que escribo. Sin embargo, trato de probar la unidad lo más posible.