让我们使用与我对相关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();
    }
}

您有几个选项，具体取决于您要测试的内容：
您可以运行aspectj编译器并验证其控制台输出（启用了编织信息），以确保预期的连接点是实际编织的，而其他连接点不是。但这更像是对aspectj配置和构建过程的测试，而不是真正的集成测试。
类似地，您可以创建一个新的编织类加载器，加载方面，然后加载几个类（loadtimeweaving，ltw），以便动态检查编织的内容和不编织的内容。在这种情况下，您要测试的是切入点是否正确，而不是由核心+方面代码组成的集成应用程序。
最后，但并非最不重要的一点是，您可以执行一个正常的集成测试，假设在核心+方面代码正确编织之后应用程序应该如何运行。如何做到这一点取决于您的具体情况，特别是您的方面为核心代码添加了什么样的副作用。
随后，我将介绍第3种选择。查看上面的示例代码，我们可以看到以下副作用：
对于较小的正数，方面会将原始参数值传递给拦截的方法，唯一的副作用是额外的日志输出。
对于负数，方面将通过取反的参数值（例如，将-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 并且确保对于较大的正数抛出预期的异常。