2016-06-07 9 views
2

В качестве бизнес-правила мы запрещаем использование определенного пространства имен , когда внутри этого другого пространства имен.Возможно ли в C# для модульного теста или анализа кода определить, используется ли пространство имен в классе?

Пример:

using X.A; //Allowed 
using X.B; //Not allowed 

namespace X.C 
{ 
    const string abc = X.A.MyClass.ABC; //Allowed 
    const string def = X.B.MyClass.DEF; //Not allowed, because we are using X.B 

    public void MyMethod() 
    { 
     string ghi = X.A.MyClass.GHI; //Allowed 
     string jkl = X.B.MyClass.JKL; //Not allowed because we are using X.B 
     string mno = "X.B.MyClass.MNO"; //Allowed, because we are not accessing X.B 
    } 
} 

Можно ли управлять этим с помощью теста блока, с помощью анализа кода, или оба, так что мы можем легко применять этот бизнес-правило, а не полагаться на просмотр кода, который может легко пропустить такую ​​вещь? Предполагая, что это возможно, как бы вы это сделали?

+4

Какова цель такого правила? Это действительно не кажется полезным. Почему бы вам просто не удалить ссылку на сборку? – poke

+0

Модульные тесты предназначены для проверки _results_, а не _implementation_. Анализ кода, вероятно, можно было бы использовать для обнаружения этого использования. Если вы хотите сейчас спросить _how_, это можно сделать, добавьте это к своему вопросу и укажите инструмент для анализа кода _which_, который вы хотите использовать. –

+1

Две или более сборки могут совместно использовать одну и ту же иерархию пространства имен. Вы можете поместить 'X.A' в одну dll и' X.B' в другую. Но на самом деле, контроль доступа по пространству имен неудобен, и вы будете бороться с инструментом, чтобы он работал. –

ответ

2

Такое правило возможно с помощью инструмента NDepend that let's write code rule through C# LINQ queries и check such rules live in Visual Studio и in your Build Process.

Конкретно такое правило может выглядеть следующим образом:

warnif count > 0 from n in Namespaces where 
n.IsUsing ("NUnit.Core.Extensibility") && 
(n.Name == @"NUnit.Core.Builders") 
select new { n, n.NbLinesOfCode } 
// the namespace NUnit.Core.Builders 
// shouldn't use directly 
// the namespace NUnit.Core.Extensibility 
// because (TODO insert your reason) 

... и это правило может быть отредактированы и выполнены/исполнение вживую в Visual Studio. NDepend Namespace Rule Edited in Visual Studio

На самом деле вы можете создать такое правило кода с помощью одного клика от dependency graph или от dependency matrix:

NDepend Dependency Graph

Такое правило правило можно записать и исполняться в юнит-тестов, поскольку NDepend обеспечивает и API.

Вы также можете быть заинтересованы нашим white books concerning structuring code through namespaces and assemblies.

Отказ от ответственности: Я работаю для NDepend.