¿Deberíamos usar FxCop en ensambles de UnitTest?

Question

Utilizamos FxCop para todos nuestros proyectos. Para nuestros UnitTests, no estoy seguro de que valga la pena. Terminamos con muchas supresiones:

[SuppressMessage("Microsoft.Performance", "CA1822:MarkMembersAsStatic", Justification = SuppressJustifications.CA1822MethodIsUsedExternallyAsNonStatic)]
[SuppressMessage("Microsoft.Usage", "CA1806:DoNotIgnoreMethodResults", MessageId = "Cantaloupe.Seed.Security.RijndaelEncryption", Justification = SuppressJustifications.CA1806MethodIsCalledForExceptionThrowingTest)]

¿Qué piensa la gente sobre el código de prueba de FxCop on Unit?

Answer 1

Cuando enseño nuestra clase de prueba de unidad / TDD, generalmente le digo a las personas que escriban el código de prueba siguiendo los mismos principios que lo harían al escribir el código de producción prober. Sin embargo, reconozco que algunas de las reglas de FxCop pueden generar demasiado ruido.

¿No podría usar un subconjunto adecuado de las reglas de FxCop para el código de prueba?

Answer 2

no vale la pena el esfuerzo; FxCop es para estándares de codificación de producción, no para código de prueba interno

(sin embargo, no está de más darle un repaso y una revisión de vez en cuando, en caso de que le diga algo útil ...)

Answer 3

Sí, pero no tienes que ser un maníaco al respecto. Sus pruebas son el mejor amigo de su codificador de mantenimiento. Si sus pruebas no son fáciles de leer, su codificador de mantenimiento lo pasará mal. Creo que ayuda a fomentar mejores hábitos, el código de prueba de unidad no tiene una licencia permisiva para ser descuidado.

Answer 4

Adelante si tienes tiempo libre. No es una mala idea hacer que el policía eche un vistazo a todo su código.