Приводит CA1822 к плохому дизайну для современного развития, когда дело доходит до модульного тестирования?

Question

Мы используем анализ кода на сервере сборки с жестким ограничением, которое мы не можем выполнить код, если правило анализа кода ломается. CA1822 включен, и поэтому у нас много статических функций. Теперь мы хотим провести единичные тесты с насмешкой и зависимостью. Но с нашими многими статическими функциями нелегко издеваться над некоторой статической функцией. Особенно, когда статическая функция вызывает статическую функцию. Я думаю об отключении CA1822, чтобы уменьшить статические функции, потому что я сам себя спрашиваю: Является ли CA1822 устаревшим для разработки с насмешливым fw и кодом? Я читал во многих других вопросах, что производительность не в этом. Так что же сделать статическую функцию? По моему мнению, CA1822 ведет к плохому дизайну. Я ошибаюсь?

Answer 1

CA1801 - это правило ReviewUnusedParameters. CA1822 - это MarkMembersAsStatic, который, как я предполагаю, на самом деле вызывает проблемы для вас.

Хорошей новостью является то, что ни одно из этих правил не срабатывает для реализации интерфейса, поэтому у вас не должно быть проблем с любым правилом, если вы начнете развязать через интерфейсы, чтобы включить инверсию управления и макетную замену для модульного тестирования ,