단위 테스트 unit-testing

tutorial/unit-testing-startGitHub의 분기를 확인합니다.

$ cd aem-guides-wknd
$ git checkout tutorial/unit-testing-start

Maven 기술을 사용하여 로컬 AEM 인스턴스에 코드 베이스를 배포합니다.

$ mvn clean install -PautoInstallSinglePackage

$ mvn clean install -PautoInstallSinglePackage -Pclassic

이러한 종속성을 보려면 aem-guides-wknd/pom.xml ​에서 Parent Reactor POM을 열고 <dependencies>..</dependencies>로 이동한 다음 <!-- Testing -->에서 io.wcm에서 제공하는 JUnit, Mockito, Apache Sling Mocks, and AEM Mock Tests의 종속성을 확인합니다.

io.wcm.testing.aem-mock.junit54.1.0 으로 설정되어 있는지 확인합니다.

<dependency>
    <groupId>io.wcm</groupId>
    <artifactId>io.wcm.testing.aem-mock.junit5</artifactId>
    <version>4.1.0</version>
    <scope>test</scope>
</dependency>

aem-guides-wknd/core/pom.xml ​을 열고 해당 테스트 종속성이 사용 가능한지 확인합니다.

코어 프로젝트의 병렬 소스 폴더에는 단위 테스트와 지원 테스트 파일이 포함됩니다. 이 테스트 폴더는 테스트 클래스를 소스 코드에서 분리하지만 테스트가 소스 코드와 동일한 패키지에 있는 것처럼 작동할 수 있도록 합니다.

테스트할 Java™ 클래스의 위치를 반영하는 Java™ 패키지 폴더 구조에서 src/test/java 아래에 새 Java™ 클래스를 만들어서 BylineImpl.java에 대한 단위 테스트를 만듭니다.

현재 테스트 중이기 때문에

• src/main/java/com/adobe/aem/guides/wknd/core/models/impl/BylineImpl.java

해당 단위 테스트 Java™ 클래스를 다음에서 생성합니다.

• src/test/java/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.java

단위 테스트 파일 BylineImplTest.java의 Test 접미사는 다음을 허용하는 규칙입니다.

1. 이는 BylineImpl.java에 대한 테스트 파일로 쉽게 식별할 수 있습니다.
2. 또한 동시에 테스트 파일을 테스트 대상인 BylineImpl.java 클래스​ 와 구별할 수 있습니다.

다음 코드로 파일을 업데이트합니다.

package com.adobe.aem.guides.wknd.core.models.impl;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class BylineImplTest {

    @BeforeEach
    void setUp() throws Exception {

    }

    @Test
    void testGetName() {
        fail("Not yet implemented");
    }

    @Test
    void testGetOccupations() {
        fail("Not yet implemented");
    }

    @Test
    void testIsEmpty() {
        fail("Not yet implemented");
    }
}

첫 번째 메서드 public void setUp() { .. }은 JUnit의 @BeforeEach 주석이 달려 있습니다. 이 주석은 JUnit 테스트 실행기가 해당 클래스의 각 테스트 메서드를 실행하기 전에 이 메서드를 실행하도록 지시합니다. 이는 모든 테스트에 필요한 공통 테스트 상태를 초기화하는 데 편리한 장소를 제공합니다.

후속 메서드는 테스트 메서드로, 규칙에 따라 이름 앞에 test가 붙고 @Test 주석이 표시됩니다. 아직 테스트가 구현되지 않았기 때문에 기본적으로 모든 테스트는 실패하도록 설정되어 있습니다.

먼저 테스트하려는 클래스의 각 공개 메서드에 대해 단일 테스트 메서드부터 시작하며, 여기에는 다음이 해당됩니다.

이러한 메서드는 필요에 따라 확장될 수 있습니다. 관련 내용은 챕터 뒷부분에서 살펴보겠습니다.

이 JUnit 테스트 클래스(JUnit 테스트 케이스라고도 함)가 실행되면 @Test로 표시된 각 메서드는 통과하거나 실패할 수 있는 테스트로 실행됩니다.

BylineImplTest.java 파일을 마우스 오른쪽 버튼으로 클릭한 다음 실행 을 탭하여 JUnit 테스트를 실행합니다.
테스트가 아직 구현되지 않았기 때문에 예상대로 모든 테스트가 실패합니다.

마우스 오른쪽 버튼으로 BylineImplTests.Java 클릭 > 실행

@ExtendWith로 표시된 JUnit 확장 기능을 BylineImplTest.java 파일에 AMD 컨텍스트로 추가함으로써 BylineImplTest.java ​에서 wcm.io의 AemContext를 사용하여 AEM 컨텍스트를 만듭니다. 확장 기능은 필요한 모든 초기화 및 정리 작업을 처리합니다. 모든 테스트 메서드에 사용할 수 있는 AemContext에 대한 클래스 변수를 만듭니다.

import org.junit.jupiter.api.extension.ExtendWith;
import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;
...

@ExtendWith(AemContextExtension.class)
class BylineImplTest {

    private final AemContext ctx = new AemContext();

이 ctx 변수는 일부 AEM 및 Sling 추상화를 제공하는 모의 AEM 컨텍스트를 노출합니다.

• BylineImpl Sling 모델은 이 컨텍스트에 등록됩니다.
• 이 컨텍스트에서 모의 JCR 콘텐츠 구조가 생성됩니다.
• 이 컨텍스트에서 사용자 정의 OSGi 서비스를 등록할 수 있습니다.
• SlingHttpServletRequest 오브젝트, ModelFactory, PageManager, Page, Template, ComponentManager, Component, TagManager, Tag 등과 같은 다양한 모의 Sling 및 AEM OSGi 서비스 등 일반적으로 요구되는 다양한 모의 오브젝트와 Helper를 제공합니다.
  • 이러한 오브젝트에 대한 모든 메서드가 구현되어 있는 것은 아닙니다!
• 그 외 여러 기능이 있습니다!

ctx 오브젝트는 대부분의 모의 컨텍스트에 대한 진입점 역할을 합니다.

각 @Test 메서드 이전에 실행되는 setUp(..) 메서드에서는 공통 모의 테스트 상태를 정의합니다.

@BeforeEach
public void setUp() throws Exception {
    ctx.addModelsForClasses(BylineImpl.class);
    ctx.load().json("/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.json", "/content");
}

• addModelsForClasses ​는 테스트할 Sling 모델을 모의 AEM 컨텍스트에 등록하므로 @Test 메서드에서 인스턴스화할 수 있습니다.
• load().json ​은 리소스 구조를 모의 컨텍스트에 로드하여 코드가 실제 저장소에서 제공된 것처럼 이러한 리소스와 상호 작용할 수 있도록 합니다. BylineImplTest.json 파일 내 리소스 정의는 /content ​에서 모의 JCR 컨텍스트에 로드됩니다.
• BylineImplTest.json ​은 아직 존재하지 않으므로, 이를 생성하고 테스트에 필요한 JCR 리소스 구조를 정의하겠습니다.

모의 리소스 구조를 나타내는 JSON 파일은 JUnit Java™ 테스트 파일과 동일한 패키지 경로 지정을 따라 core/src/test/resources 아래에 저장됩니다.

core/test/resources/com/adobe/aem/guides/wknd/core/models/impl에서 다음 내용이 포함된 BylineImplTest.json ​이라는 JSON 파일을 만듭니다.

{
    "byline": {
    "jcr:primaryType": "nt:unstructured",
    "sling:resourceType": "wknd/components/content/byline"
    }
}

이 JSON은 Byline 구성 요소 단위 테스트를 위한 모의 리소스(JCR 노드)를 정의합니다. 이 시점에서 JSON은 Byline 구성 요소 콘텐츠 리소스를 표현하는 데 필요한 최소한의 속성 세트인 jcr:primaryType 및 sling:resourceType을 갖습니다.

단위 테스트를 수행할 때의 일반적인 규칙은 각 테스트를 충족하는 데 필요한 최소한의 모의 콘텐츠, 컨텍스트 및 코드 세트를 만드는 것입니다. 테스트를 작성하기 전에 완전한 모의 컨텍스트를 구성해야 한다는 생각을 피하는 것이 좋습니다. 불필요한 아티팩트가 생기는 경우가 많기 때문입니다.

이제 BylineImplTest.json ​이 존재하므로, ctx.json("/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.json", "/content") 실행 시 모의 리소스 정의가 /content 경로에서 컨텍스트에 로드됩니다.

다음과 같이 BylineImplTest.Java ​에서 testGetName() 메서드를 업데이트합니다.

import com.adobe.aem.guides.wknd.core.models.Byline;
...
@Test
public void testGetName() {
    final String expected = "Jane Doe";

    ctx.currentResource("/content/byline");
    Byline byline = ctx.request().adaptTo(Byline.class);

    String actual = byline.getName();

    assertEquals(expected, actual);
}

• String expected ​는 예상 값을 설정합니다. 당사는 이 값을 'Jane Done'으로 설정합니다.
• ctx.currentResource ​는 코드를 평가할 모의 리소스의 컨텍스트를 설정하므로, 모의 byline 콘텐츠 리소스가 로드되는 위치인 /content/byline ​으로 설정됩니다.
• Byline byline ​은 모의 Request 오브젝트에서 Byline Sling 모델을 적용하여 인스턴스화합니다.
• String actual ​은 Byline Sling 모델 오브젝트에서 테스트하는 메서드인 getName()을 호출합니다.
• assertEquals ​는 예상 값이 Sling Model 오브젝트에서 반환된 값과 일치하는지 확인합니다. 값이 같지 않으면 테스트는 실패합니다.

테스트를 실행하는 경우 NullPointerException 오류로 실패합니다.

모의 JSON에서 name 속성을 정의하지 않았기 때문에 이 테스트는 실패하지 않습니다. 속성을 정의하면 테스트가 실패하지만 테스트 실행이 아직 그 지점에 도달하지 않았습니다. 이 테스트는 byline 오브젝트 자체의 NullPointerException 오류로 인해 실패합니다.

BylineImpl.java의 경우 @PostConstruct init()에서 오류가 발생하면 Sling 모델이 인스턴스화되지 않고 해당 Sling 모델 오브젝트가 null이 됩니다.

@PostConstruct
private void init() {
    image = modelFactory.getModelFromWrappedRequest(request, request.getResource(), Image.class);
}

ModelFactory OSGi 서비스는 AemContext를 통해(Apache Sling Context를 통해) 제공되지만 BylineImpl의 init() 메서드에서 호출되는 getModelFromWrappedRequest(...)를 비롯한 모든 메서드가 구현된 것은 아닙니다. 이로 인해 AbstractMethodError가 발생하고 그 결과 init()가 실패하게 되며 결과적으로 ctx.request().adaptTo(Byline.class)의 적응은 null 오브젝트가 됩니다.

제공된 모의 오브젝트는 당사의 코드를 수용할 수 없으므로, 당사가 직접 모의 컨텍스트를 구현해야 합니다. 이를 위해 Mockito를 사용하여 모의 ModelFactory 오브젝트를 생성할 수 있으며 이 오브젝트는getModelFromWrappedRequest(...)가 호출되면 모의 Image 오브젝트를 반환합니다.

Byline Sling 모델을 인스턴스화하려면 이 모의 컨텍스트가 있어야 하므로 이 컨텍스트를 @Before setUp() 메서드에 추가할 수 있습니다. 또한 BylineImplTest 클래스 위에서 MockitoExtension.class를 @ExtendWith 주석에 추가해야 합니다.

package com.adobe.aem.guides.wknd.core.models.impl;

import org.mockito.junit.jupiter.MockitoExtension;
import org.mockito.Mock;

import com.adobe.aem.guides.wknd.core.models.Byline;
import com.adobe.cq.wcm.core.components.models.Image;

import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;

import org.apache.sling.models.factory.ModelFactory;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;
import org.apache.sling.api.resource.Resource;

@ExtendWith({ AemContextExtension.class, MockitoExtension.class })
public class BylineImplTest {

    private final AemContext ctx = new AemContext();

    @Mock
    private Image image;

    @Mock
    private ModelFactory modelFactory;

    @BeforeEach
    public void setUp() throws Exception {
        ctx.addModelsForClasses(BylineImpl.class);

        ctx.load().json("/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.json", "/content");

        lenient().when(modelFactory.getModelFromWrappedRequest(eq(ctx.request()), any(Resource.class), eq(Image.class)))
                .thenReturn(image);

        ctx.registerService(ModelFactory.class, modelFactory, org.osgi.framework.Constants.SERVICE_RANKING,
                Integer.MAX_VALUE);
    }

    @Test
    void testGetName() { ...
}

• @ExtendWith({AemContextExtension.class, MockitoExtension.class}) ​는 Mockito JUnit Jupiter Extension으로 실행할 테스트 케이스 클래스를 표시합니다. 이를 통해 @Mock 주석을 사용하여 클래스 수준에서 모의 오브젝트를 정의할 수 있습니다.
• @Mock private Image ​는 com.adobe.cq.wcm.core.components.models.Image 유형의 모의 오브젝트를 생성합니다. 이는 클래스 수준에서 정의되므로 필요에 따라 @Test 메서드가 동작을 변경할 수 있습니다.
• @Mock private ModelFactory ​는 ModelFactory 유형의 모의 오브젝트를 생성합니다. 이는 순수한 Mockito 모의이며 구현된 메서드가 없습니다. 이는 클래스 수준에서 정의되므로 필요에 따라 @Test 메서드가 동작을 변경할 수 있습니다.
• when(modelFactory.getModelFromWrappedRequest(..) ​는 getModelFromWrappedRequest(..)가 모의 ModelFactory 오브젝트에서 호출될 때 모의 동작을 등록합니다. thenReturn (..)에 정의된 결과는 모의 Image 오브젝트를 반환하는 것입니다. 이 동작은 첫 번째 매개변수가 ctx의 요청 오브젝트와 같고, 두 번째 매개변수가 Resource 오브젝트이고, 세 번째 매개변수가 Core Components Image 클래스인 경우에만 호출됩니다. 테스트 전반에 걸쳐 ctx.currentResource(...)를​ BylineImplTest.json ​에 정의된 다양한 모의 리소스에 설정하기 때문에 모든 리소스를 허용하게 됩니다. 나중에 ModelFactory의 이러한 동작을 재정의해야 하기 때문에 lenient() 엄격성을 추가한다는 점을 참고하시기 바랍니다.
• ctx.registerService(..) ​는 가장 높은 서비스 순위를 가진 AemContext에 모의 ModelFactory 오브젝트를 등록합니다. 이 작업은 BylineImpl의 init()에서 사용되는 ModelFactory가 @OSGiService ModelFactory model 필드를 통해 주입되기 때문에 필요합니다. AemContext가 getModelFromWrappedRequest(..)에 대한 호출을 처리하는 당사의 모의 오브젝트를 주입하도록 하려면 해당 유형(ModelFactory)에서 가장 높은 순위의 서비스로 등록해야 합니다.

테스트를 다시 실행하면 또 실패하나, 이번에는 실패 이유가 명확하게 표시됩니다.

어설션으로 인한 testGetName() 실패

테스트의 삽입 조건이 실패했음을 의미하는 AssertionError ​가 표시되며 이 오류는 예상 값이 'Jane Doe' ​이나 실제 값이 null ​임을 알려 줍니다. 이는 'name' 속성이 BylineImplTest.json ​의 /content/byline 리소스 정의를 모의하는 데 추가되지 않았기 때문입니다. 따라서 이 속성을 추가해 보겠습니다.

BylineImplTest.json ​을 업데이트하여 "name": "Jane Doe".를 정의합니다.

{
    "byline": {
    "jcr:primaryType": "nt:unstructured",
    "sling:resourceType": "wknd/components/content/byline",
    "name": "Jane Doe"
    }
}

테스트를 다시 실행하면 이제 testGetName() ​이 통과됩니다.

testGetOccupations() ​를 다음과 같이 업데이트합니다.

import java.util.List;
import com.google.common.collect.ImmutableList;
...
@Test
public void testGetOccupations() {
    List<String> expected = new ImmutableList.Builder<String>()
                            .add("Blogger")
                            .add("Photographer")
                            .add("YouTuber")
                            .build();

    ctx.currentResource("/content/byline");
    Byline byline = ctx.request().adaptTo(Byline.class);

    List<String> actual = byline.getOccupations();

    assertEquals(expected, actual);
}

• List<String> expected ​는 예상 결과를 정의합니다.
• ctx.currentResource ​는 /content/byline에 있는 모의 리소스 정의에 대해 컨텍스트를 평가할 현재 리소스를 설정합니다. 이렇게 하면 BylineImpl.Java ​가 모의 리소스의 컨텍스트에서 실행됩니다.
• ctx.request().adaptTo(Byline.class) ​는 모의 Request 오브젝트에서 Byline Sling 모델을 적용하여 인스턴스화합니다.
• byline.getOccupations() ​는 Byline Sling 모델 오브젝트에서 테스트하는 메서드인 getOccupations()을 호출합니다.
• assertEquals(expected, actual) ​는 예상 목록이 실제 목록과 동일함을 확인합니다.

위의 getName() ​과 마찬가지로, BylineImplTest.json ​은 직업을 정의하지 않으므로 이 테스트를 실행하면 실패합니다. 그 이유는 byline.getOccupations()가 빈 목록을 반환하기 때문입니다.

BylineImplTest.json ​을 업데이트하여 직업 목록을 포함하도록 하고 직업이 알파벳이 아닌 순서로 설정되어 테스트에서 직업이 getOccupations() ​에 따라 알파벳순으로 정렬되도록 합니다.

{
    "byline": {
    "jcr:primaryType": "nt:unstructured",
    "sling:resourceType": "wknd/components/content/byline",
    "name": "Jane Doe",
    "occupations": ["Photographer", "Blogger", "YouTuber"]
    }
}

테스트를 실행해 보니 역시 통과했습니다! 직업을 분류한 게 맞는 것 같네요!

testGetOccupations() 통과

첫 번째 테스트는 속성이 설정되지 않은 새 구성 요소의 상태를 테스트합니다.

BylineImplTest.json에 새 리소스 정의를 추가하고 의미적론적인 이름을 '빈'으로 지정합니다.

{
    "byline": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline",
        "name": "Jane Doe",
        "occupations": ["Photographer", "Blogger", "YouTuber"]
    },
    "empty": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline"
    }
}

"empty": {...} ​는 jcr:primaryType 및 sling:resourceType만 있으며 이름이 'empty'인 새로운 리소스 정의를 정의합니다.

각 테스트 메서드를 실행하기 전에 @setUp에서 BylineImplTest.json을 ctx로 로드한다는 점을 기억하십시오. 이렇게 해야 테스트 시 /content/empty ​에서 새로운 리소스 정의를 즉각 사용할 수 있습니다.

testIsEmpty()를 다음과 같이 업데이트하고 현재 리소스를 새로운 '빈' 모의 리소스 정의로 설정합니다.

@Test
public void testIsEmpty() {
    ctx.currentResource("/content/empty");
    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

테스트를 실행하여 통과하는지 확인합니다.

다음으로 필수 데이터 포인트(이름, 직업 또는 이미지)가 비어 있는 경우 isEmpty()가 true를 반환하는 메서드 세트를 만듭니다.

각 테스트에서는 별도의 모의 리소스 정의가 사용됩니다. BylineImplTest.json ​은 이름-없음 및 직업-없음 ​에 대한 추가 리소스 정의로 업데이트합니다.

{
    "byline": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline",
        "name": "Jane Doe",
        "occupations": ["Photographer", "Blogger", "YouTuber"]
    },
    "empty": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline"
    },
    "without-name": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline",
        "occupations": "[Photographer, Blogger, YouTuber]"
    },
    "without-occupations": {
        "jcr:primaryType": "nt:unstructured",
        "sling:resourceType": "wknd/components/content/byline",
        "name": "Jane Doe"
    }
}

다음 테스트 메서드를 만들어 각 상태를 테스트합니다.

@Test
public void testIsEmpty() {
    ctx.currentResource("/content/empty");

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

@Test
public void testIsEmpty_WithoutName() {
    ctx.currentResource("/content/without-name");

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

@Test
public void testIsEmpty_WithoutOccupations() {
    ctx.currentResource("/content/without-occupations");

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

@Test
public void testIsEmpty_WithoutImage() {
    ctx.currentResource("/content/byline");

    lenient().when(modelFactory.getModelFromWrappedRequest(eq(ctx.request()),
        any(Resource.class),
        eq(Image.class))).thenReturn(null);

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

@Test
public void testIsEmpty_WithoutImageSrc() {
    ctx.currentResource("/content/byline");

    when(image.getSrc()).thenReturn("");

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertTrue(byline.isEmpty());
}

testIsEmpty() ​는 빈 모의 리소스 정의에 대해 테스트를 수행하고 isEmpty()가 참인지 확인합니다.

testIsEmpty_WithoutName() ​는 직업은 있지만 이름이 없는 모의 리소스 정의에 대해 테스트를 수행합니다.

testIsEmpty_WithoutOccupations() ​는 이름은 있지만 직업이 없는 모의 리소스 정의에 대해 테스트를 수행합니다.

testIsEmpty_WithoutImage() ​는 이름과 직업이 있는 모의 리소스 정의에 대해 테스트를 수행하지만 null을 반환하도록 모의 Image를 설정합니다. 이 호출에서 반환된 Image 오브젝트가 null이 되도록 하려면 setUp()에 정의된 modelFactory.getModelFromWrappedRequest(..) 동작을 재정의해야 합니다. Mockito 스텁 기능은 엄격하며 중복 코드를 원하지 않습니다. 따라서 당사는 setUp() 메서드에서 동작을 재정의한다는 것을 명시적으로 나타내는 lenient 설정을 사용하여 모의를 설정합니다.

testIsEmpty_WithoutImageSrc() ​는 이름과 직업을 포함한 모의 리소스 정의에 대한 테스트를 수행하지만 getSrc()가 호출되면 모의 Image가 빈 문자열을 반환하도록 설정합니다.

마지막으로, 구성 요소가 올바르게 구성된 경우 isEmpty() ​가 false를 반환하는지 확인하는 테스트를 작성합니다. 이러한 조건에서는 완전히 구성된 Byline 구성 요소를 나타내는 /content/byline ​을 재사용할 수 있습니다.

@Test
public void testIsNotEmpty() {
    ctx.currentResource("/content/byline");
    when(image.getSrc()).thenReturn("/content/bio.png");

    Byline byline = ctx.request().adaptTo(Byline.class);

    assertFalse(byline.isEmpty());
}

이제 BylineImplTest.Java 파일에서 모든 단위 테스트를 실행하고 Java™ 테스트 보고서 출력을 검토합니다.