Проверить зависимости между пространствами имен через отражение

У меня есть два отдельных пространства имен в моей сборке: DataAccess и DomainLogic.Проверить зависимости между пространствами имен через отражение

Мне нужен фрагмент кода, проверяющий, что ни один класс в DomainLogic не зависит от пространства имен DataAccess.

Как бы вы это сделали?

PS: Я думаю, что я видел пример такого модульного теста в замечательной книге Марка Семанна Dependency Injection in .Net, но у меня нет его здесь, и я не могу найти пример с помощью Google.

Редактировать

Поскольку все реакции до сих пор указывают на то, что я должен просто разделить эти взаимозависимые классы в двух разных сборок, я хотел бы отметить, что это в настоящее время не вариант (хотя это действительно один из моих главных целей в конце). Я имею дело с устаревшим кодом, и я просто не могу реорганизовать его в один большой взрыв прямо сейчас. Отдельные пространства имен и проверка зависимостей между ними являются промежуточным этапом. Как только этот тест пройдет, я могу продолжить и переместить часть кода в другую сборку.

источник

2013-11-01 EagleBeak

Почему вы не можете просто поместить их в отдельных сборках? – Agares

Я знаю, что это не то, о чем вы просите, но одна альтернатива - переместить их в отдельные проекты и просто не ссылаться на «DataAccess» из «DomainLogic». –

@Agares: Я не могу сейчас, потому что это устаревший код, и я реорганизую его. Я хочу победить хаос, сначала разделив классы на разные пространства имен, а затем и другие сборки. Даже тогда мне бы хотелось, чтобы проверка проверяла, что сборка «DomainLogic» не зависит от «DataAccess». – EagleBeak

Весь код в сборке может законно получить доступ к общедоступному и внутреннему коду на всей остальной части сборки. Поэтому такие модульные тесты, даже если это возможно, были бы плохой идеей.

Если вы разделили типы DataAccess на отдельный проект и сделали его внутренним, ничто не сможет получить к нему доступ. Ясно, что вы не хотите. Однако, разделив его, вы можете гарантировать, что DomainAccess может получить доступ к DomainLogic, но не наоборот. Это, по-видимому, то, что вы хотите.

В то же время вместо того, чтобы пытаться разработать модульные тесты, чтобы проверить, что правило «DomainLogic не должно иметь доступа к DomainAccess», вместо этого используйте проверки кода. Предполагая, что вы используете гибкие методы (если нет, сделайте это!), Все действия будут задокументированы как задачи. Никакая задача не может считаться «сделанной», пока кто-то, кто понимает и не примет ваше правило, не пересмотрел изменения кода для задачи. Разбейте правило, и задача не завершит проверку кода и должна быть переработана до его завершения.

источник

2013-11-01 11:32:32

См. Изменение в моем вопросе. Я рефакторинг устаревшего кода. – EagleBeak

@ EagleBeak Я могу это понять. Я обновил свой ответ предложением о том, как с этим бороться. –

Вы абсолютно правы, и я ценю вход, но это все еще не то, что я просил.Мне нужен инструмент для облегчения этой конкретной задачи рефакторинга. Я отредактировал формулировку моего вопроса, чтобы уточнить, что фрагмент кода - это все, что мне нужно. (Фактически autmated test не имеет никакого смысла, так как он всегда терпит неудачу. Как только он пройдет, я смогу создать новую сборку и больше не нуждаюсь в этом тесте.) – EagleBeak

Есть инструмент, который выполняет только это: проверяет зависимости пространства имен на основе ваших правил и нарушений отчетов во время сборки в качестве предупреждений или ошибок. Это называется NsDepCop, бесплатно, с открытым исходным кодом.

Правила конфигурация будет выглядеть следующим образом:

<NsDepCopConfig IsEnabled="True" CodeIssueKind="Warning"> 
    <Allowed From="*" To="*" /> 
    <Disallowed From="DomainLogic" To="DataAccess" /> 
</NsDepCopConfig>

источник

2015-08-07 12:31:57 Vizu

Проверить зависимости между пространствами имен через отражение

ответ

Смежные вопросы