首页 > 代码库 > Net中的AOP
Net中的AOP
返回《.Net中的AOP》系列学习总目录
本篇目录
- 使用NUnit编写测试
- 编写和运行NUnit测试
- 切面的测试策略
- Castle DynamicProxy测试
- 测试一个拦截器
- 注入依赖
- PostSharp测试
- 对PostSharp切面进行单元测试
- 注入依赖
- PostSharp和测试的问题
- 小结
本节的源码本人已托管于Coding上：点击查看。
本系列的实验环境：VS 2013 Update 5（建议最好使用集成了Nuget的VS版本，VS Express版也够用）。
这节我们说说AOP中的单元测试。单元测试对于保障一款产品的质量还是很重要的，当你写了一个开源的东西，最好要对它进行单元测试通过后再分享，不然别人如何知道你的东西最后会不会出问题；楼主现在从事的一家互联网金融公司也是需要做单元测试的，而且还做了自动化测试（楼主目前主导从事AT这块，以后会分享关于AT的文章），毕竟这都是和大笔资金有关的，不确保产品的质量就上线是不行的，不做测试有时上线产品也是没有自信的，谁也无法确保自己写的代码不出bug,而单元测试和自动化测试都通过后，就会信心十足，虽然还是会出bug。如果你们做的是TDD（测试驱动开发），毫无疑问要写单元测试，这样才能驱动编码的设计和架构。好了，关于测试的话题，以后有机会分享，现在切入今天的正题当使用了AOP后，如何进行单元测试？
使用NUnit编写测试
如果你写过单元测试（UT），那么这篇博客说的东西你应该很熟悉。这儿使用一个.Net单元测试常见的工具NUnit来复习一下单元测试。如果你更喜欢其它的测试工具或框架也是没问题的，仍然可以继续阅读，重要的是思想。
NUnit
NUit是免费开源的，而且具有良好的文档说明，因而收到很多人喜爱。除了NUnit之外，其它的测试框架如MSTest，MSpec，xUnit.net 等都是一些好的测试框架。因此，你喜欢哪个或者使用哪个更顺手就选择哪个吧。
如果你还没有编写UT的习惯，或者从来都没谢过UT，建议你最好尽快学会这门技术，迟早派的上用场的。UT是一个大的话题，因此一篇博客不可能全部覆盖到，因此，建议之后自己阅读一下测试的书籍。
编写和运行NUnit测试
首先创建一个类库项目，取名 UnitTestDemo，之后创建一个string的扩展类MyStringExtension,具体代码如下：
public class MyStringExtension
{
/// <summary>
/// 创建一个反转字符串的方法，比如 输入hello，返回olleh
/// </summary>
/// <param name="str"></param>
/// <returns></returns>
public string Reverse(string str)
{
return str;//现在暂时直接返回，为了看看测试的效果
}
}
现在应该准备测试的工具了，使用Nuget安装NUnit:PM> Install-Package NUnit。安装之后，第一步是写一个Test Fixture（测试装备），它是一个包含了Test的类（可能也包含setup/teardown代码）。使用NUnit编写Test Fixture很简单，只需要在一个类上使用TestFixture特性就可以了：
[TestFixture]
public class MyStringExtensionTest
{
}
在这个Test Fixture里面，写一个简单的测试验证一下Reverse方法是否和自己预想的一样。测试一般遵循3A模式，即Arrange(准备阶段)， Act(执行阶段)， Assert（断言阶段）。
- Arrange：创建一个被测类的新实例；
- Act：给Reverse方法传入一个字符串并获得返回结果；
- Assert：检查字符串是否按预期的那样反转了。
按照3A模式，写出的代码如下：
[TestFixture]
public class MyStringExtensionTest
{
[Test]
public void Reverse_Test()
{
var myStrObj=new MyStringExtension();
var reversedStr = myStrObj.Reverse("hello");
Assert.That(reversedStr,Is.EqualTo("olleh"));//断言语法根据使用的工具和爱好不同可以有很多写法
}
}
因为我们还没有正确实现Reverse方法，所以测试应该是失败的。如果你已经安装了Resharp或者TestDriven.net，那么可以使用这些工具运行测试，楼主已经安装了Resharp，所以可以直接运行测试。当然你可以安装NUnit的一些测试工具。
测试失败的截图如下：
正确实现Reverse方法：
public string Reverse(string str)
{
//return str;//现在暂时直接返回，为了看看测试的效果
return new string(str.Reverse().ToArray());
}
通过的单元测试截图如下：
这时你就开始考虑更多的情况了，比如，如果传入的是null，就返回null，因为Reverse方法没有对null做检查，因此会抛出NullReferenceException，因此我们先写测试用例：
[Test]
public void ReverseWithNull_Test()
{
var myStrObj=new MyStringExtension();
var reversedStr = myStrObj.Reverse(null);
Assert.IsNull(reversedStr);
}
测试结果失败：
在Reverse方法中加入null判断：
public string Reverse(string str)
{
if (string.IsNullOrEmpty(str))
{
return null;
}
//return str;//现在暂时直接返回，为了看看测试的效果
return new string(str.Reverse().ToArray());
}
再次执行测试用例，通过：
切面的测试策略
谈到测试切面时，一般要测两个东西：一是切面是否用在了正确的地方（测试切入点），二是切面是否完成了预期的事情（测试通知）。.Net中的AOP工具通常通过特性使用切面，我们在PostSharp和MVC ActionFilter中看到过了。要测试特性是否用在了正确的地方，只需要测试特性是否用在了我们期望的类和方法上即可。
回忆一下，当在VS中创建了一个 ASP.NET MVC 项目时，会自动创建一个AccountController,该控制器中的一些方法使用了ValidateAntiForgeryToken特性（这就是一个ActionFilter）。创建项目时，同时勾选创建单元测试项目复选框时，也会为我们创建一个单元测试的项目，默认使用的微软VS自带的Microsoft.VisualStudio.QualityTools.UnitTestFramework测试框架。
默认在测试项目中帮我们生成了一个测试Home控制器的类：
假如我们要测试一下那些特性是否处于正确的地方，比如测试一下使用了ValidateAntiForgeryToken特性的LogOff方法：
// POST: /Account/LogOff
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult LogOff()
{
AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
return RedirectToAction("Index", "Home");
}在VS帮我们创建的测试项目中新建一个AccountControllerTest单元测试类，创建测试用例如下：
[TestMethod]
public void LogOff()
{
var classUnderTest = typeof (AccountController);
var allMethods = classUnderTest.GetMethods();//获得所有方法
var methodUnderTest = allMethods.Where(m => m.Name == "LogOff");//获得LogOff方法
foreach (MethodInfo methodInfo in methodUnderTest)
{
var attribute = Attribute.GetCustomAttribute(methodInfo, typeof (ValidateAntiForgeryTokenAttribute));//寻找方法上的ValidateAntiForgeryTokenAttribute特性
Assert.IsNotNull(attribute);//如果存在，测试通过
}
}
通过微软自带的测试框架写的测试类，在测试项目生成之后，会在测试资源管理器中出现所有可以运行的测试方法：
运行测试用例，通过：
上面的代码使用了System.Reflection来获取类，方法，方法上的特性，然后断言特性是否为null。注意，这个测试不是为了测试ValidateAntiForgeryTokenAttribute特性做了什么，而是它是否出现在正确的地方。
有些人可能认为这样做太冗余了或者这样做过犹不及，他们也都有似乎合理的理由，但是在一个大的团队或者项目中，有时很难跟踪应该使用哪些切面，并且这些很容易忘记，所以这些类型的测试也是很有用的。
对于像使用了IoC容器而不是特性的DynamicProxy来说，测试切面是否存在稍微有些不同。如果你已经编写了测试来验证选择的IoC工具是否初始化正确，那么也应该同时测试动态代理。
对切面编写测试可能因工具选择的不同而不同，因开发者、框架不同而不同，因此变化可能很大，本系列教程主要使用Castle DynamicProxy和PostSharp来讲解。
Castle DynamicProxy测试
使用Castle DynamicProxy写的切面只实现了IInterceptor接口，其它方面，就像一个普通的类：编译、实例化、在运行时执行（这和PostSharp切面不同，后者在编译时实例化，并在编译时执行部分代码）。因此，测试使用Castle DynamicProxy的切面就像测试POCO类一样简单。
首先看一下如何测试一个最简单切面，该切面是自我包含的且没有任何依赖。然后看一下如何测试使用DI解析依赖的简单切面。如果你熟悉DI在单元测试中扮演的角色，那么测试DynamicProxy类应该很熟悉。
测试一个拦截器
假设有个拦截器，使用了静态的Log类在方法执行前后输出一些信息。首先创建一个静态Log类存储字符串，如下：
public static class Log
{
private static List<string> _messages=new List<string>();
public static List<string> Messages
{
get { return _messages; }
}
public static void Write(string message)
{
_messages.Add(message);
}
}
下一步，写一个使用了这个类的拦截器。并在拦截的方法执行前后输出一些信息：
public class MyInterceptor:IInterceptor
{
public void Intercept(IInvocation invocation)
{
Log.Write(invocation.Method.Name+"执行前");
invocation.Proceed();
Log.Write(invocation.Method.Name+"执行后");
}
}
之前已经看到过使用Castle DynamicProxy写的切面了，但如何测试呢？既然拦截器是一个常规的类，那就可以实例化一个对象，然后调用它的Intercept方法，然后检查一下记录的日志是否和预期的一样。顺着这个思路，写出的代码如下：
[TestFixture]
public class MyInterceptorTest
{
[Test]
public void TestIntercept()
{
var myInterceptor=new MyInterceptor();
IInvocation invocation;//这里先不赋值，下面接着说
myInterceptor.Intercept(invocation);
Assert.IsTrue(Log.Messages.Contains(invocation.Method.Name+"执行前"));
Assert.IsTrue(Log.Messages.Contains(invocation.Method.Name+"执行后"));
}
}
因为上面的invocation变量没有赋值，所以编译是不通过的。如果你之前做过单元测试的话，那么你也应该知道单元测试中有这么一个概念：伪造【mocking】。
当拦截器在程序中运行时，DynamicProxy会创建invocation对象，它对于测试来说是隔离的，因此我们必须伪造一个对象来模拟真正的invocation对象，伪造的目的仅仅是为了测试。为了达到这个目的，这里使用了一个伪造工具Moq，虽然还有很多可以用，但是这里使用Moq作为示例。使用Nuget安装Moq：PM> Install-Package Moq。
现在，创建一个实现了IInvocation接口的伪造对象，然后将它传给Intercept方法，因为Intercept方法只关心invocation.Method.Name,所以只需要给那个伪造对象定义那个属性就可以了，Moq会给其它属性设置默认值：
[Test]
public void TestIntercept()
{
var myInterceptor=new MyInterceptor();
//IInvocation invocation;//这里先不赋值，下面接着说
var mockedInvocation=new Mock<IInvocation>();
mockedInvocation.Setup(m => m.Method.Name).Returns("MyMethod");//Arrange:将被拦截的方法的Name属性设置为MyMethod
var invocation = mockedInvocation.Object;//使用Object属性获得要传入的真实对象
myInterceptor.Intercept(invocation);
Assert.IsTrue(Log.Messages.Contains(invocation.Method.Name+"执行前"));
Assert.IsTrue(Log.Messages.Contains(invocation.Method.Name+"执行后"));
}
现在可以编译运行了，当运行该测试时，测试应该通过。如果进一步看一下Moq的话，你就会发现Moq本身使用了DynamicProxy。因此，在一定程度上，我们使用了DynamicProxy切面测试其它的DynamicProxy切面，这是没有任何问题的，因为我们不是在测试框架本身而是使用框架生成的代码。测试结果如下：
注入依赖
真实项目中，使用上面的静态Log类会造成Log类和任何用到它的地方之间紧耦合，因此，应该使用logging接口，并隐藏实现细节。和写切面是一样的：你想将依赖传入MyInterceptor类中。切面和其它模块是一样的，应该遵守依赖反转原则，应该依赖抽象而不是实现。
加入IoC
IoC工具在一个复杂点的例子里会实用点，因此下面创建一个比之前复杂的例子。见下面的案例图：
实现服务
创建一个控制台项目CastleDynamicProxyUT，添加NUnit，Castle.Core,StructureMap。注意这里安装的StructureMap版本是Install-Package structuremap -Version 2.6.4.1。
下面，按照上图从下到上实现，创建接口IServiceTwo和它的实现ServiceTwo，里面添加一个方法DoWorkTwo,这里仅仅作为演示，具体该方法中有什么代码不重要。
命名惯例
这里使用的是ServiceName和IServiceName的命名惯例，因为这是StructureMap使用的默认惯例。当配置依赖时，只要遵守了这个惯例，就不必显式列出每个接口/实现对。
public interface IServiceTwo
{
void DoWorkTwo();
}
public class ServiceTwo:IServiceTwo
{
public void DoWorkTwo()
{
throw new System.NotImplementedException();
}
}
下一步，创建LoggingService的实现和接口。真实项目中，这个服务都会使用NLog，log4net等等，但这里为了简单演示，只将日志输出到控制台，这个日志服务可能会用在项目中的任何地方，但是通过logging切面使用的。
public interface ILoggingService
{
void Write(string message);
}
public class LoggingService : ILoggingService
{
public void Write(string message)
{
Console.WriteLine("Logging:"+message);
}
}
编写Logging切面
该切面依赖LoggingService，通过构造函数注入可以获得ILoggingService依赖。在Intercept方法中，它在拦截的方法执行前后分别输出“Log start”和“Log end”：
public class LoggingAspect:IInterceptor
{
private readonly ILoggingService _loggingService;
public LoggingAspect(ILoggingService loggingService)
{
_loggingService = loggingService;
}
public void Intercept(IInvocation invocation)
{
_loggingService.Write("Log start");
invocation.Proceed();
_loggingService.Write("Log end");
}
}
对切面进行单元测试
上面的切面不像之前的测试那样简单，因为这个切面多个依赖。我们只想测试切面，不想测试依赖，因此需要使用伪造工具创建一个代替对象传入LoggingAspect构造函数，这样就可以独立地测试切面了,记得要安装Moq。
[TestFixture]
public class LoggingAspectTest
{
[Test]
public void TestIntercept()
{
var mockedLoggingService=new Mock<ILoggingService>();//为ILoggingService创建一个伪造对象
var loggingAspect=new LoggingAspect(mockedLoggingService.Object);//使用伪造对象的Object属性实例化LoggingAspect
var mockedInvocation=new Mock<IInvocation>();//为IInvoation对象创建一个伪造对象
loggingAspect.Intercept(mockedInvocation.Object);
mockedLoggingService.Verify(x=>x.Write("Log start"));//使用伪造对象的Verify验证Write方法是否像期待的那样执行
mockedLoggingService.Verify(x=>x.Write("Log end"));
}
}
测试DynamicProxy的切面是很容易的，但我们还没有看到全局，因此，继续按照示意图完成其它依赖的代码。这个切面需要拦截ServiceOne的任何调用。
创建ServiceOne
创建ServiceOne实现和接口。这个服务没有做太多的事情，只是输出到控制台，示意图上说明它会依赖ServiceTwo接口，因此在构造函数中要确保它传入，虽然传入了依赖，但为了演示目的，这里并没有真正使用该依赖：
public interface IServiceOne
{
void DoWorkOne();
}
public class ServiceOne:IServiceOne
{
public ServiceOne(IServiceTwo serviceTwo)
{
//虽然没有使用IServiceTwo依赖，但是没有它，ServiceOne是不能实例化的
}
public void DoWorkOne()
{
Console.WriteLine("ServiceOne‘s DoWorkOne finished the execution!");
}
}
随着例子越来越复杂，StructureMap就会派上用场了。在没使用StructureMap之前，先来看看没有IoC工具时程序如何使用ServiceOne。要在Main方法中使用ServiceOne，因为它依赖ServiceTwo，所以必须先要实例化ServiceTwo：
class Program
{
static void Main(string[] args)
{
#region 1.0 不使用StructureMap的情况
var service2=new ServiceTwo();
var service1=new ServiceOne(service2);
service1.DoWorkOne();
#endregion
}
}
运行程序的话，就会在控制台看到“ServiceOne‘s DoWorkOne finished the execution!”。
使用IOC工具管理依赖
代码执行结果看起来没问题，但是在Main方法中依赖了特定的实现new ServiceTwo(),new ServiceOne(service2)违反了依赖反转原则，这会造成这两个服务类和Program类紧耦合。从架构设计的角度来说这是一个设计缺陷，而且想象一下如果有一个更复杂的依赖关系图呢：每次调用一个服务上的一个方法时，你可能都要花费5行以上的代码实例化所有的对象。
对于这种情况，我们应该使用StructureMap管理依赖，并实例化正确的服务。这样，就不用来new特定的实现了，只需要命令StructureMap完成某个接口的实现就可以了。下面看一下使用默认惯例的StructureMap的基本配置：
#region 2.0 使用StructureMap
ObjectFactory.Initialize(config =>//不同的IOC工具初始化代码是不同的
{
config.Scan(scanner =>
{
scanner.TheCallingAssembly();
scanner.WithDefaultConventions();//使用默认的惯例
});
});
var service1 = ObjectFactory.GetInstance<IServiceOne>();
service1.DoWorkOne();
运行程序，会看到和之前一样的输出，但是这次StructureMap会帮我们处理依赖图中的所有依赖连接。
DynamicProxy和StructureMap结合
前面已经知道，需要使用ProxyGenerator可以将一个DynamicProxy切面应用到一个类上。前面几篇博客中，我们都是在StructureMap的配置中处理的，但是ServceOne有一个依赖，因此比之前更复杂了。
StructureMap自带的拦截
如果你熟悉StructureMap，那么你应该知道它有自己的拦截能力，比如InstanceInterceptor接口。对于确定类型的装饰器，这个工具够用了，但是DynamicProxy有个更强大的拦截工具，所以这里不使用StructureMap的InstanceInterceptor。
一种方法是实例化切面和它的依赖，实例化服务类和它的依赖，这样就可以将切面应用到服务上了：
ObjectFactory.Initialize(config =>//不同的IOC工具初始化代码是不同的
{
config.Scan(scanner =>
{
scanner.TheCallingAssembly();
scanner.WithDefaultConventions();//使用默认的惯例
});
var proxyGenerator = new ProxyGenerator();
var aspect = new LoggingAspect(new LoggingService());
var service = new ServiceOne(new ServiceTwo());
var result = proxyGenerator.CreateInterfaceProxyWithTargetInterface(typeof(IServiceOne), service, aspect);//应用切面
config.For<IServiceOne>().Use((IServiceOne) result);//告诉StructureMap使用产生的动态代理
});
这种方法有几个问题：
- 首先最明显的就是美观问题：将一个切面应用到一个服务类上要写很多的代码。
- 应该使用一种方法让StructureMap处理依赖而不是大量的new。
- 可能不太明显，如果想使用一个切面多次呢？如果继续使用这种方法，StructureMap初始化可能会变得非常凌乱。
使用EnrichWith重构
幸运的是，我们可以结合一个helper类和StructureMap的叫做EnrichWith的功能来精简代码。StructureMap的EnrichWith方法可以用于注册一个方法来代替正常服务的对象，就像注入一个拦截器的最佳地方。下面将大部分的凌乱代码放到EnrichWith语句中：
#region 3.0 使用EnrichWith重构
ObjectFactory.Initialize(config =>
{
config.Scan(scanner =>
{
scanner.TheCallingAssembly();
scanner.WithDefaultConventions();
});
var proxyGenerator = new ProxyGenerator();
config.For<IServiceOne>().Use<ServiceOne>().EnrichWith(svc =>
{
var aspect = new LoggingAspect(new LoggingService());
var result = proxyGenerator.CreateInterfaceProxyWithTargetInterface(typeof(IServiceOne), svc, aspect);
return result;
});
});
#endregion
比之前的代码好多了，但是每次使用一个切面仍然要输入很多东西。进一步优化，我们可以把EnrichWith里的代码尽可能多地封装到可复用的代理创建类里，最好像下面的代码那样：
ObjectFactory.Initialize(config =>
{
config.Scan(scanner =>
{
scanner.TheCallingAssembly();
scanner.WithDefaultConventions();
});
var proxyHelper = new ProxyHelper();
//注意Proxify方法本身以实参传入EnrichWith方法
config.For<IServiceOne>().Use<ServiceOne>().EnrichWith(proxyHelper.Proxify<IServiceOne, LoggingAspect>);
});
上面的代码更加简洁，使用EnrichWith方法只用到了proxyHelper的Proxify方法，服务接口和切面类。
使用ProxyHelper
上面我们已经看到了这个类，只需要将代理生成器中的代码放到这个类中就可以了。在这个帮助类中，会使用ObjectFactory来解析拦截器对象。
public class ProxyHelper
{
private readonly ProxyGenerator _proxyGenerator;
public ProxyHelper()
{
_proxyGenerator = new ProxyGenerator();//ProxyGenerator移到helper类中
}
public object Proxify<I, A>(object obj) where A : IInterceptor//约束A只允许IInterceptor类型实参
{
var interceptor = (IInterceptor) ObjectFactory.GetInstance<A>();//StructureMap处理切面的依赖
var result = _proxyGenerator.CreateInterfaceProxyWithTargetInterface(typeof (I),obj,interceptor);
return result;
}
}
这小节的主题是对使用DynamicProxy写的切面进行单元测试，所以关于IOC的知识及优化大家可以自己去研究。研究出来的结果就是对使用DynamicProxy写的切面进行单元测试并不是很难。下面一节，我们会对使用PostSharp写的切面进行单元测试。
PostSharp测试
使用PostSharp编写的切面继承自抽象基类，比如OnMethodBoundaryAspect。它们也是特性，存储在元数据中，因此，没有PostSharp这个postcompiler（后编译，就是代码编译之后再加工）工具，这些特性什么都不会做，也不会执行。该后编译工具会在编译时实例化切面类，序列化，然后再反序列化。因此，直接测试这些切面类是很困难的，在某些情况下，由于后编译编织的本质和PostSharp框架写入的方式直接进行测试根本是行不通的。
对PostSharp切面进行单元测试
之前我们创建了一个静态的Log类，这次也一样，但切面类是不同的：它继承自PostSharp的OnMethodBoundaryAspect基类。这次会重写OnEntry和OnSuccess方法，并在这两个方法内输出日志：
[Serializable]
public class MyBoundaryAspect:OnMethodBoundaryAspect
{
public override void OnEntry(MethodExecutionArgs args)
{
Log.Write("Before:"+args.Method.Name);
}
public override void OnSuccess(MethodExecutionArgs args)
{
Log.Write("After:" + args.Method.Name);
}
}
对于上面类的单元测试和之前的很相似，如下，我们不需要使用Moq，可以直接实例化一个MethodExecutionArgs对象，该对象的构造函数期望一个实例对象和一个参数列表，但因为这里MyBoundaryAspect用不到这些，我们分别使用null和Arguments.Empty代替。切面类使用了Method属性，因此我们需要将它设置为实现了MethodBase的某个对象，通过使用System.Reflection提供的DynamicMethod对象，可以很方便地达到目的。对于测试，这里只关心方法名，因此返回类型和参数类型可以设置为null。
接下来就该写执行了，这里实例化一个切面对象，并先后调用OnEntry和OnSuccess方法，模拟在运行时切面被使用的时候发生了什么。
最后，会输出两个断言，看看预期的和实际的日志信息是否相同。
[TestFixture]
public class TestMyLoggerCrossCutConcern
{
[Test]
public void TestMyBoundaryAspect()
{
//Arrange 准备阶段
var args = new MethodExecutionArgs(null, Arguments.Empty);
args.Method = new DynamicMethod("Farb", null, null);
//Act 执行阶段
var aspect = new MyBoundaryAspect();
aspect.OnEntry(args);
aspect.OnSuccess(args);
//Assert 断言阶段
Assert.IsTrue(Log.Messages.Contains("Before:" + args.Method.Name));
Assert.IsTrue(Log.Messages.Contains("After:" + args.Method.Name));
}
}
当然，也可以使用伪造工具创建一个代替MethodExecutionArgs的对象，但因为它不是一个接口或抽象类，所以必须使用一个更高级的伪造工具，如TypeMock，Moq不能实现这个。下面复习一下DynamicProxy中的复杂例子，看看使用PostSharp会有什么不同。
注入依赖
之前的例子使用了StructureMap结合DynamicProxy，依赖通过构造函数注入，使用了PostSharp，切面构造函数会在编译时调用，这个过程在StructureMap初始化之前。因此，构造函数注入是没用的，这就意味着测试更加困难。为了解决这个问题，这里用到了服务定位器模式。
服务定位器是依赖反转的一种形式，与通过构造函数传入服务相反，它会去寻找服务。有时人们认为服务定位模式是反模式，但是，它确实好于压根不用依赖反转。
这一小节，创建一个控制台项目PostSharpUT，安装PostSharp和NUnit，StructureMap，复习一下和之前一样复杂的依赖。
class Program
{
static void Main(string[] args)
{
ObjectFactory.Initialize(x =>
{
x.Scan(scan =>
{
scan.TheCallingAssembly();
scan.WithDefaultConventions();
});
});
var myObj = ObjectFactory.GetInstance<IServiceOne>();
myObj.DoWorkOne();
}
}
服务类和接口与之前的保持不变，IServiceOne , ServiceOne ,
IServiceTwo , ServiceTwo , ILoggingService ,LoggingService直接使用之前项目中的。
LoggingAspect现在继承了OnMethodBoundaryAspect基类，而不是Castle的IInterceptor接口，里面使用了ILoggingService的实现，因此应该使用一个私有字段：
[Serializable]
public class LoggingAspect:OnMethodBoundaryAspect
{
private readonly ILoggingService _loggingService;
public LoggingAspect(ILoggingService loggingService)
{
_loggingService = loggingService;
}
public override void OnEntry(MethodExecutionArgs args)
{
_loggingService.Write("Log start");
}
public override void OnSuccess(MethodExecutionArgs args)
{
_loggingService.Write("Log end");
}
}
PostSharp构造器只能以特性的形式使用，C#特性构造器只接受静态值，因此不能像上面那样注入LoggingService依赖。但是可以使用还没有提到的一个PostSharp API，这就是RuntimeInitialize方法。PostSharp会在运行时执行该方法，但是在运行时方法如OnEntry和OnSuccess方法之前（对LocationInterceptionAspect和MethodInterceptionAspect也适用）。重写该方法，在方法中使用StructureMap作为服务定位器来初始化_loggingService。也需要将_loggingService使用特性标记为NonSerialized，因为直到该切面反序列化之后它才会被初始化。
[Serializable]
public class LoggingAspect:OnMethodBoundaryAspect
{
[NonSerialized]
private ILoggingService _loggingService;
public override void RuntimeInitialize(MethodBase method)
{
_loggingService = ObjectFactory.GetInstance<ILoggingService>();
}
public override void OnEntry(MethodExecutionArgs args)
{
_loggingService.Write("Log start");
}
public override void OnSuccess(MethodExecutionArgs args)
{
_loggingService.Write("Log end");
}
}
现在这个切面就可用了，然后，将这个切面以特性的形式用在ServiceOne的DoWorkOne上：
[LoggingAspect]
public void DoWorkOne()
{
Console.WriteLine("ServiceOne‘s DoWorkOne finished the execution!");
}
执行结果：
对上面的代码进行单元测试就需要多做点工作了。创建一个测试类和测试方法，和之前一样，在测试中，需要创建ILoggingService的一个Mock对象（如果没有安装Moq先要使用Nuget安装Moq）。再创建一个要传入的MethodExecutionArgs对象，它不需要有Method属性，因为我们这次没有用到它：
[TestFixture]
public class MyLoggingAspectTest
{
[Test]
public void TestIntercept()
{
var mockedLoggingService=new Mock<ILoggingService>();
var args=new MethodExecutionArgs(null,Arguments.Empty);
}
}
如果使用的是Castle，我们接下来就要实例化切面对象，然后将mockedLoggingAspect对象传给构造函数，但如果使用了PostSharp，就不能那么做了。做法是必须将mockedLoggingAspect对象传给StructureMap，让它实例化切面对象，然后执行RuntimeInitialize方法，它会向StructureMap请求ILoggingService对象：
[TestFixture]
public class MyLoggingAspectTest
{
[Test]
public void TestIntercept()
{
var mockedLoggingService = new Mock<ILoggingService>();
var args=new MethodExecutionArgs(null,Arguments.Empty);
ObjectFactory.Initialize(x =>
x.For<ILoggingService>().Use(mockedLoggingService.Object));
var loggingAspect=new LoggingAspect();
loggingAspect.RuntimeInitialize(null);
loggingAspect.OnEntry(args);
loggingAspect.OnSuccess(args);
}
}
当OnEntry方法执行时，我们期望loggingService调用Write方法，并输出含有“Log Start”的信息。同样，当执行OnSuccess方法时，我们期望输出含有“Log end”的信息。下面根据单元测试的3A法则，应该验证我们的预期和实际是否相符了：
mockedLoggingService.Verify(x=>x.Write("Log start"));
mockedLoggingService.Verify(x=>x.Write("Log end"));
执行该测试，测试会通过。这次我们也实现了和之前使用Castle DynamicProxy相似级别的测试，只不过做的事情多了些罢了。
别急，好戏还在下面。
PostSharp和测试的问题
当对PostSharp切面做单元测试时，你会面临很多问题。
第一个问题是PostSharp在编译时编织。对后来会修改的代码测试变得复杂。
编译时编织
考虑下面的代码段：
public class MyStringExtension
{
public string Reverse(string str)
{
return new string(str.Reverse().ToArray());
}
}
[TestFixture]
public class MyStringExtensionTest
{
[Test]
public void Reverse_Test()
{
var myStrObj=new MyStringExtension();
var reversedStr = myStrObj.Reverse("hello");
Assert.That(reversedStr,Is.EqualTo("olleh"));
}
}
这是本文开头的例子，传入字符串变量“hello”，然后返回反转后的字符串“olleh”。现在，思考相同的PostSharp切面LoggingAspect应用到该方法会怎样。
public class MyStringExtension
{
[LoggingAspect]
public string Reverse(string str)
{
return new string(str.Reverse().ToArray());
}
}
在运行时执行的Reverse方法现在会在LoggingAspect类的代码中执行。因此，RuntimeInitialize方法会被执行，然后切面使用StructureMap获得ILoggingService的依赖。现在，Reverse_Test就会变得有点复杂了。我们需要再次伪造ILoggingService，并且初始化StructureMap来获得可代替的对象，因为这是个单元测试，我们对测试logging不感兴趣，只对Reverse方法感兴趣。
[Test]
public void Reverse_Test()
{
var mockloggingService=new Mock<ILoggingService>();
ObjectFactory.Initialize(x=>
x.For<ILoggingService>().Use(mockloggingService.Object));
var myStrObj=new MyStringExtension();
var reversedStr = myStrObj.Reverse("hello");
Assert.That(reversedStr,Is.EqualTo("olleh"));
}
虽然已经使用了切面完成了漂亮的关注点分离（反转字符串的类和logging类），但运行单元测试时，它们仍然是紧耦合的，因此仍然需要做些额外的工作来分离测试中的伪造对象。此外，编写UT时，需要伪造的服务类是不明显的，因为它不是唯一要实例化切面的。如果忘了一个，那么测试就会失败，因为StructureMap会抛异常。
最后一个是服务定位器的问题，在这个demo中，直接把ObjectFactory.Initialize放在单元测试中不是问题，因为只有一个UT，但是如果这是个静态方法，当写多个UT时，就必须关心共享状态。比如，当在ObjectFactory中初始化ILoggingService的伪造对象时，该伪造对象会为每个UT保持注册。解决方案就是在你的代码（单元测试，RuntimeInitialize）和StructureMap之间添加一层处理逻辑。这会让UT花费更多功夫。
总之，当编写涉及PostSharp的UT时，很困难。虽然收获了将横切关注点分离到不同的类中的好处，但UT必须做些特殊的处理代码。使用Castle DynamicProxy时不会出现这个问题。
关闭PostSharp的变通方法
PostSharp可以通过VS中的项目属性设置进行关闭，可以临时关闭PostSharp,运行单元测试，然后当测试通过后再打开即可。这种方法几乎不理想，感兴趣的，你可以试试。
另一种变通是使用编译器宏指令。比如，你自定义了一个指令UnitTesting,就可以使用#if语句包裹切面代码，如果UnitTesting指定定义了的话，就会编译一个空切面，这就是说，你可以不需要额外的伪造就可以运行UT了。
#define UnitTesting
[Serializable]
public class LoggingAspect:OnMethodBoundaryAspect
{
#if !UnitTesting
[NonSerialized]
private ILoggingService _loggingService;
public override void RuntimeInitialize(MethodBase method)
{
_loggingService = ObjectFactory.GetInstance<ILoggingService>();
}
public override void OnEntry(MethodExecutionArgs args)
{
_loggingService.Write("Log start");
}
public override void OnSuccess(MethodExecutionArgs args)
{
_loggingService.Write("Log end");
}
#endif
}
}
[Test]
public void Reverse_Test()
{
var myStrObj=new MyStringExtension();//这个UT就不需要关心伪造对象了
var reversedStr = myStrObj.Reverse("hello");
Assert.That(reversedStr,Is.EqualTo("olleh"));
}
这个办法也几乎不理想，你必须通过定义UnitTesting指定来打开和关闭PostSharp（或者至少找到一种自动化方式）。还有，必须用#if/#end来包围切面类的所有代码。
一个相似的选择是定义一个全局变量来指示切面代码是否应该运行。这个变量默认是true，但在UT中，可以设置为false。
public static class AspectSettings
{
public static bool On = true;
}
[Serializable]
public class LoggingAspect2:OnMethodBoundaryAspect
{
[NonSerialized]
private ILoggingService _loggingService;
public override void RuntimeInitialize(MethodBase method)
{
if(!AspectSettings.On) return;
_loggingService = ObjectFactory.GetInstance<ILoggingService>();
}
public override void OnEntry(MethodExecutionArgs args)
{
if (!AspectSettings.On) return;
_loggingService.Write("Log start");
}
public override void OnSuccess(MethodExecutionArgs args)
{
if (!AspectSettings.On) return;
_loggingService.Write("Log end");
}
}
[Test]
public void Reverse_Test()
{
AspectSettings.On = false;//关闭设置
var myStrObj=new MyStringExtension();
var reversedStr = myStrObj.Reverse("hello");
Assert.That(reversedStr,Is.EqualTo("olleh"));
}
这种变通可能是最简单的方法了，因为不必担心伪造、共享状态，服务定位器问题或者其他问题了。当测试时，切面会关闭。这仍然不方便，因为必须切面的设置，以确保所有的UT都关闭了切面。
不可访问的构造函数
如果上面所有的问题你觉得都不是问题，那么还有一个问题。
本文的例子中，使用的是OnMethodBoundaryAspect。使用的参数类是MethodExecutionArgs,幸运地是它有一个公共的构造函数。另外两个PostSharp切面基类（位置拦截和方法拦截）使用了LocationInterceptionArgs和MethodInterceptionArgs，它们都没有公共的构造函数。这使得创建伪造或者可代替的对象更加困难，你可以使用更高级的伪造工具，如TypeMock（不免费）。
间接测试PostSharp
该说的都说了，该做的也都做了，可能不值得花费精力直接测试PostSharp切面类。应该做的就是保持切面中的代码最小化。切面可能只包含实例化和执行其他类的代码，也就是说，你可以在PostSharp切面类和执行横切关注点的代码之间创建一个间接层。下图展示了PostSharp的例子，但相同的原则也可以用于DynamicProxy或任何其他的切面框架。
一定程度上，这种方式和MVP模式很相似。View是PostSharp切面本身，Presenter是处理工作的分离的类（logging之前，logging之后等等）。切面中的代码极少，因为已经将它的工作委托给一个横切关注点对象（concern）。该横切关注点对象是一个POCO，比如，一个没有继承自PostSharp基类的对象更容易测试。
public class MyNormalCode
{
[MyThinAspect]
public string Reverse(string content)
{
return new string(content.Reverse().ToArray());
}
}
[Serializable]
public class MyThinAspect:OnMethodBoundaryAspect
{
private IMyCrossCuttingConcern _concern;//该切面只有一个StructureMap提供的IMyCrossCuttingConcern依赖
public override void RuntimeInitialize(MethodBase method)
{
if(!AspectSettings.On) return;
_concern = ObjectFactory.GetInstance<IMyCrossCuttingConcern>();
}
public override void OnEntry(MethodExecutionArgs args)
{
if (!AspectSettings.On) return;
_concern.BeforeMethod("before");//委托给BeforeMethod方法
}
public override void OnSuccess(MethodExecutionArgs args)
{
if (!AspectSettings.On) return;
_concern.AfterMethod("after");//委托给AfterMethod方法
}
}
public interface IMyCrossCuttingConcern
{
void BeforeMethod(string logMsg);
void AfterMethod(string logMsg);
}
所有通知代码可以放到IMyCrossCuttingConcern的实现中：
public class MyCrossCuttingConcern:IMyCrossCuttingConcern
{
private ILoggingService _loggingService;
public MyCrossCuttingConcern(ILoggingService loggingService)
{
_loggingService = loggingService;
}
public void BeforeMethod(string logMsg)
{
_loggingService.Write(logMsg);
}
public void AfterMethod(string logMsg)
{
_loggingService.Write(logMsg);
}
}
MyCrossCuttingConcern很容易测试，因为它和任何AOP框架都不是紧耦合的，构造函数注入再次变得可行。
小结
谈到UT时，Castle DynamicProxy有明显优势，PostSharp的UT至少处于中级难度并且要求更多的代码。
好的软件架构绝大多数都知道做出正确的权衡，并且基于软件的类型和开发目标变化也很灵活。
如果你认为UT很重要，那么不要完全依赖PostSharp。后面，我们还会看一下PostSharp可以提供一些运行时编织工具不能提供的测试形式。PostSharp提供了编译时验证和架构验证，这些都是在编译时发生的。比如，可以使用PostSharp在架构级验证代码（这样，确保所有的NHibernate实体属性都正确地定义为virtual）。
本文开始暴露的一点是运行时编织工具（Castle DynamicProxy）和后编译时编织工具（PostSharp）有很大的不同。如果只看本文的开头部分，你会看到PostSharp更强大、更灵活，但是最后涉及到UT时，你会看到它这么强大和灵活所付出的代价。
Net中的AOP