Должны ли мы использовать FxCop на сборках UnitTest?

Question

Мы используем FxCop для всех наших проектов. Для наших UnitTests я не уверен, что оно того стоит. В итоге мы получаем множество подавлений:

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

Что думают люди о FxCop в коде модульного теста?

Answer 1

Когда я преподаю наш модульный тест / класс TDD, я обычно говорю людям писать тестовый код, следуя тем же принципам, что и при написании кода пробного производства. Тем не менее, я признаю, что некоторые правила FxCop могут генерировать слишком много шума.

Не могли бы вы использовать подходящее подмножество правил FxCop для тестового кода?

Answer 2

не стоит усилий; FxCop предназначен для стандартов производственного кодирования, а не для внутреннего тестового кода.

(тем не менее, не мешало бы ему время от времени показывать и повторять, на случай, если он скажет вам что-нибудь полезное ...)

Answer 3

Да, но вы не должны быть маньяком в этом. Ваши тесты - лучший друг вашего технического специалиста. Если ваши тесты не так легко прочитать, вашему кодеру обслуживания придется нелегко. Я думаю, что это помогает поощрять лучшие привычки, код модульного теста не имеет разрешительной лицензии, чтобы быть небрежным.

Answer 4

Идите вперед, если у вас есть время. Неплохая идея заставить полицейского взглянуть на весь ваш код.