AspectJ 的集成测试

2022-01-14 00:00:00 integration-testing mockito java junit aspectj

我正在尝试为自定义方面编写集成测试.这是方面类代码段.

I am trying to write Integratation tests for Custom Aspect. Here is the 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();

    }

}

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

So the above aspect intercepts whenever jointpoint matches the pointcut. Its working fine. But my question is how to perform Integration test.

我所做的是我在 Aspect 中创建了属性count"以进行跟踪，并在我的 Junit 中声明它.我不确定这是否好，或者是否有更好的方法对方面进行集成测试.

What I have done is I created the attribute "count" in Aspect for tracking and asserted it in my Junit. I am not sure if this is good or is there a better way of doing integration testing on aspects.

这是我所做的 Junit 的片段.我的表现很糟糕，但我希望我为集成测试所做的事情是无法理解的.

Here is the snippet of Junit what I have done. I presented in bad way but I hope its undestandable of what I have done for Integration testing.

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

推荐答案

让我们使用与 我对相关的 AspectJ 单元测试问题:

要按方面定位的 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();
    }
}

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

You have several options, depending on what exactly you want to test:

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

接下来我将描述选项号.3.查看上面的示例代码，我们看到以下副作用:

Subsequently I will describe option no. 3. Looking at the sample code above, we see the following side effects:

  • 对于小的正数，aspect 通过 original 参数值传递给被拦截的方法，唯一的副作用是额外的日志输出.
  • 对于负数，aspect 会通过 negated 参数值(例如将 -22 变为 22)传递到被截获的方法，这是很好的可测试性.
  • 对于较大的正数，方面会引发异常，从而完全停止执行原始方法.

方面的集成测试:

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;
        }
    }
}

等等，我们正在通过检查日志输出到 System.out 的模拟实例并确保抛出预期的异常来准确测试示例方面的三种副作用更大的正数.

Et voilà, we are testing exactly the three types of side effects our sample aspect has by inspecting log output to a mock instance of System.out and by making sure that the expected exception is thrown for larger positive numbers.

相关文章