AspectJ的集成测试

我正在尝试为Custom Aspect编写Integratation测试。 这是Aspect Class Snippet。

@Aspect @Component public class SampleAspect { private static Logger log = LoggerFactory.getLogger(SampleAspect.class); private int count; public int getCount(){ return count; } public void setCount(){ this.count= count; } @Around("execution(* org.springframework.data.mongodb.core.MongoOperations.*(..)) || execution(* org.springframework.web.client.RestOperations.*(..))") public Object intercept(final ProceedingJoinPoint point) throws Throwable { logger.info("invoked Cutom aspect"); setCount(1); return point.proceed(); } } 

因此,只要关节点与切入点匹配,上述方面就会截获。 它的工作正常。 但我的问题是如何执行集成测试。

我所做的是在Aspect中创建了属性“count”,用于跟踪并在我的Junit中声明它。 我不确定这是好还是有更好的方法对方面进行集成测试。

这是Junit的片段,我做了什么。 我提出的方式很糟糕,但我希望它对我在集成测试中所做的工作是不可靠的。

 @Test public void testSamepleAspect(){ sampleAspect.intercept(mockJointPoint); Assert.assertEquals(simpleAspect.getCount(),1); } 

让我们使用与我对相关AspectJunit testing问题的答案相同的示例代码:

方面要定位的Java类:

 package de.scrum_master.app; public class Application { public void doSomething(int number) { System.out.println("Doing something with number " + number); } } 

测试方面:

 package de.scrum_master.aspect; import org.aspectj.lang.ProceedingJoinPoint; import org.aspectj.lang.annotation.Around; import org.aspectj.lang.annotation.Aspect; @Aspect public class SampleAspect { @Around("execution(* doSomething(int)) && args(number)") public Object intercept(final ProceedingJoinPoint thisJoinPoint, int number) throws Throwable { System.out.println(thisJoinPoint + " -> " + number); if (number < 0) return thisJoinPoint.proceed(new Object[] { -number }); if (number > 99) throw new RuntimeException("oops"); return thisJoinPoint.proceed(); } } 

您有多种选择,具体取决于您要测试的内容:

  1. 您可以运行AspectJ编译器并validation其控制台输出(启用编织信息),以确保预期的连接点实际编织而其他连接点不是。 但这应该是对AspectJ配置和构建过程的测试,而不是真正的集成测试。
  2. 类似地,您可以创建一个新的编织类加载器,加载方面,然后加载几个类(加载时编织,LTW),以动态检查编织的内容和不编织的内容。 在这种情况下,您宁愿测试您的切入点是否比由核心+方面代码组成的集成应用程序正确。
  3. 最后,但并非最不重要的是,您可以执行正常的集成测试,假设应用程序在核心+方面代码编织正确后应该如何表现。 如何做到这一点取决于您的具体情况,特别是您的方面添加到核心代码的副作用。

随后我将描述选项号。 3.查看上面的示例代码,我们看到以下副作用:

  • 对于小的正数,方面将原始参数值传递给截取的方法,唯一的副作用是额外的日志输出。
  • 对于负数,方面通过否定的参数值(例如,将-22变为22)到截取的方法,这是可以很好地测试的。
  • 对于较大的正数,该方面会抛出exception ,从而有效地停止原始方法的执行。

方面的集成测试:

 package de.scrum_master.aspect; import static org.junit.Assert.assertEquals; import static org.mockito.ArgumentMatchers.matches; import static org.mockito.Mockito.times; import static org.mockito.Mockito.verify; import java.io.PrintStream; import org.junit.*; import org.junit.Before; import org.junit.Rule; import org.junit.Test; import org.mockito.Mock; import org.mockito.junit.MockitoJUnit; import org.mockito.junit.MockitoRule; import de.scrum_master.app.Application; public class SampleAspectIT { @Rule public MockitoRule mockitoRule = MockitoJUnit.rule(); private Application application = new Application(); private PrintStream originalSystemOut; @Mock private PrintStream fakeSystemOut; @Before public void setUp() throws Exception { originalSystemOut = System.out; System.setOut(fakeSystemOut); } @After public void tearDown() throws Exception { System.setOut(originalSystemOut); } @Test public void testPositiveSmallNumber() throws Throwable { application.doSomething(11); verify(System.out, times(1)).println(matches("execution.*doSomething.* 11")); verify(System.out, times(1)).println(matches("Doing something with number 11")); } @Test public void testNegativeNumber() throws Throwable { application.doSomething(-22); verify(System.out, times(1)).println(matches("execution.*doSomething.* -22")); verify(System.out, times(1)).println(matches("Doing something with number 22")); } @Test(expected = RuntimeException.class) public void testPositiveLargeNumber() throws Throwable { try { application.doSomething(333); } catch (Exception e) { verify(System.out, times(1)).println(matches("execution.*doSomething.* 333")); verify(System.out, times(0)).println(matches("Doing something with number")); assertEquals("oops", e.getMessage()); throw e; } } } 

Etvoilà,我们通过检查日志输出到System.out的模拟实例并确保为更大的正数引发预期的exception来测试我们的示例方面所具有的三种类型的副作用。