단위 테스트 unit-testing

GitHub에서 tutorial/unit-testing-start 분기 확인

$ 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 ​에서 상위 Reactor POM을 열고 <dependencies>..</dependencies>(으)로 이동한 다음 <!-- Testing -->에서 io.wcm을 통해 JUnit, Mockito, Apache Sling Mocks 및 AEM Mock Tests에 대한 종속성을 확인하십시오.

io.wcm.testing.aem-mock.junit5이(가) 4.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 ​을(를) 열고 해당 테스트 종속성을 사용할 수 있는지 확인합니다.

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

테스트할 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. 테스트 파일 for 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 테스트 실행자에게 이 메서드를 실행하도록 지시하는 JUnit의 @BeforeEach 주석이 추가됩니다. 이렇게 하면 모든 테스트에 필요한 일반적인 테스트 상태를 초기화할 수 있는 편리한 위치를 제공합니다.

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

먼저 테스트 중인 클래스의 각 공용 메서드에 대한 단일 테스트 메서드로 시작하므로

이 방법은 이 장의 뒷부분에서 살펴보겠지만 필요에 따라 확장될 수 있습니다.

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

BylineImplTest.java 파일을 마우스 오른쪽 단추로 클릭하고 실행 ​을 탭하여 JUnit 테스트 사례를 실행합니다.
예상대로 모든 테스트가 아직 구현되지 않아 실패합니다.

BylineImplTests.java를 마우스 오른쪽 단추로 클릭 > 실행

BylineImplTest.java 파일에 @ExtendWith(으)로 데코레이트된 JUnit 확장명으로 추가하여 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 서비스와 같이 필요한 다양한 모의 개체와 도우미를 제공합니다.
  • 이 개체에 대해 일부 메서드가 구현되지 않았습니다!
• 훨씬 더!

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")을(를) 실행하면 모의 리소스 정의가 경로 /콘텐츠의 컨텍스트에 로드됩니다.

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 ​은(는) 코드를 평가할 모의 리소스의 컨텍스트를 설정하므로 이 값은 /content/byline(으)로 설정되며 여기서 모의 byline 콘텐츠 리소스가 로드됩니다.
• Byline byline ​은(는) 모의 요청 개체에서 Byline Sling 모델을 조정하여 인스턴스화합니다.
• String actual ​은(는) Byline Sling Model 개체에서 테스트 중인 메서드 getName()을(를) 호출합니다.
• assertEquals ​은(는) 예상 값이 byline Sling Model 개체에서 반환된 값과 일치함을 어설션합니다. 이 값이 같지 않으면 테스트가 실패합니다.

테스트를 실행하면 NullPointerException(으)로 실패합니다.

모의 JSON에 name 속성을 정의하지 않았으므로 이 테스트가 실패하지 않습니다. 이렇게 하면 테스트 실행이 해당 시점에 도달하지 않았더라도 테스트가 실패합니다. byline 개체 자체의 NullPointerException(으)로 인해 이 테스트가 실패합니다.

BylineImpl.java에서 @PostConstruct init()에서 예외를 throw하면 Sling 모델이 인스턴스화되지 못하고 해당 Sling 모델 개체가 null이 됩니다.

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

ModelFactory OSGi 서비스가 Apache Sling 컨텍스트를 통해 AemContext을(를) 통해 제공되는 동안 BylineImpl의 init() 메서드에서 호출되는 getModelFromWrappedRequest(...)을(를) 포함하여 모든 메서드가 구현되지는 않습니다. 이렇게 하면 AbstractMethodError이(가) 발생하고, 이로 인해 init()이(가) 실패하며, 결과 ctx.request().adaptTo(Byline.class)의 조정은 null 개체입니다.

제공된 Mock이 코드를 수용할 수 없으므로 직접 Mock 컨텍스트를 구현해야 합니다. 이를 위해 Mockito를 사용하여 getModelFromWrappedRequest(...)이(가) 호출될 때 Mock Image 개체를 반환하는 Mock ModelFactory 개체를 만들 수 있습니다.

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

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}) ​은(는) @Mock 주석을 사용하여 클래스 수준에서 모의 개체를 정의할 수 있도록 하는 Mockito JUnit Jupiter Extension으로 실행할 테스트 사례 클래스를 표시합니다.
• @Mock private Image ​이(가) com.adobe.cq.wcm.core.components.models.Image 형식의 모의 개체를 만듭니다. 필요에 따라 @Test 메서드가 필요에 따라 동작을 변경할 수 있도록 클래스 수준에서 정의됩니다.
• @Mock private ModelFactory ​이(가) ModelFactory 형식의 모의 개체를 만듭니다. 이것은 순수한 모키토 모의이며, 그 위에 구현된 방법이 없습니다. 필요에 따라 @Test메서드가 필요에 따라 동작을 변경할 수 있도록 클래스 수준에서 정의됩니다.
• when(modelFactory.getModelFromWrappedRequest(..) ​은(는) getModelFromWrappedRequest(..)이(가) mock ModelFactory 개체에서 호출될 때 모의 동작을 등록합니다. thenReturn (..)에 정의된 결과는 모의 이미지 개체를 반환하는 것입니다. 이 동작은 첫 번째 매개 변수가 ctx의 요청 개체와 같고, 두 번째 매개 변수가 임의의 Resource 개체이며, 세 번째 매개 변수가 Core Components Image 클래스여야 하는 경우에만 호출됩니다. 테스트 전체에서 ctx.currentResource(...)을(를) BylineImplTest.json ​에 정의된 다양한 모의 리소스로 설정하고 있으므로 모든 리소스를 허용합니다. 나중에 ModelFactory의 이 동작을 재정의하려고 하므로 lenient() 제한을 추가합니다.
• ctx.registerService(..) ​이(가) 서비스 순위가 가장 높은 AemContext에 mock ModelFactory 개체를 등록합니다. BylineImpl의 init()에 사용된 ModelFactory가 @OSGiService ModelFactory model 필드를 통해 삽입되므로 이 작업이 필요합니다. AemContext에서 getModelFromWrappedRequest(..)에 대한 호출을 처리하는 our 모의 개체를 삽입하려면 해당 형식의 최상위 서비스(ModelFactory)로 등록해야 합니다.

테스트를 다시 실행하고 실패해도 이번에는 메시지가 실패한 이유를 명확하게 알 수 있습니다.

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

테스트에서 어설션 조건이 실패했음을 의미하는 AssertionError ​이(가) 수신되며 이는 예상 값이 "Jane Doe" ​이지만 실제 값이 null임 ​을 알려줍니다. BylineImplTest.json ​의 mock /content/byline 리소스 정의에 "name" 속성이 추가되지 않았으므로 적절하므로 추가하겠습니다.

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) ​은(는) 모의 요청 개체에서 Byline Sling 모델을 조정하여 인스턴스화합니다.
• byline.getOccupations() ​은(는) Byline Sling Model 개체에서 테스트 중인 메서드 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"]
    }
}

테스트를 실행하면 다시 통과합니다! 정렬된 직업을 만드는 것이 효과가 있는 것 같습니다!

testGetOccuptions() 통과

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

의미 체계 이름 "empty"을(를) 지정하여 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의 테스트에서 이 새 리소스 정의를 즉시 사용할 수 있습니다.

현재 리소스를 새로운 "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()이(가) true임을 확인합니다.

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

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

testIsEmpty_WithoutImage() ​은(는) 이름과 직업을 가진 모의 리소스 정의에 대해 테스트하지만 모의 이미지가 null로 반환되도록 설정합니다. 이 호출에서 반환된 Image 개체가 null인지 확인하기 위해 setUp()에 정의된 modelFactory.getModelFromWrappedRequest(..) 동작을 재정의하려고 합니다. Mockito 스텁 기능은 엄격하며 중복 코드를 원하지 않습니다. 따라서 lenient 설정으로 모의를 설정하여 setUp() 메서드의 동작을 재정의하고 있음을 명시적으로 확인합니다.

testIsEmpty_WithoutImageSrc() ​은(는) 이름 및 직업을 가진 모의 리소스 정의에 대해 테스트하지만 getSrc()을(를) 호출할 때 빈 문자열을 반환하도록 모의 이미지를 설정합니다.

마지막으로, 구성 요소가 올바르게 구성되면 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™ 테스트 보고서 출력을 검토합니다.