返回《.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（断言阶段）。

1. Arrange：创建一个被测类的新实例；
2. Act：给Reverse方法传入一个字符串并获得返回结果；
3. 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属性设置为MyMethodvar 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属性实例化LoggingAspectvar 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使用产生的动态代理
});

这种方法有几个问题：

1. 首先最明显的就是美观问题：将一个切面应用到一个服务类上要写很多的代码。
2. 应该使用一种方法让StructureMap处理依赖而不是大量的new。
3. 可能不太明显，如果想使用一个切面多次呢？如果继续使用这种方法，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时，你会看到它这么强大和灵活所付出的代价。