기능 테스트

기능 테스트는 세 가지 유형으로 분류됩니다.

• 제품 기능 테스트
• 사용자 지정 기능 테스트
• 사용자 지정 UI 테스트

제품 기능 테스트

제품 기능 테스트는 AEM의 핵심 기능(예: 작성 및 복제)에 대한 안정적인 HTTP 통합 테스트 세트로서, 이 핵심 기능을 위반하는 경우 애플리케이션 코드에 대한 고객 변경 사항이 배포되지 않도록 합니다.

고객이 Cloud Manager에 새 코드를 배포할 때마다 제품 기능 테스트가 자동으로 실행되며 건너뛸 수 없습니다.

샘플 테스트를 보려면 제품 기능 테스트를 참조하십시오.

사용자 지정 기능 테스트

파이프라인의 사용자 지정 기능 테스트 단계가 항상 존재하며 건너뛸 수 없습니다.

그러나 빌드에 의해 테스트 JAR이 생성되지 않으면 테스트가 기본적으로 전달됩니다.

사용자 지정 UI 테스트

AEM은 고객에게 Cloud Manager 품질 게이트의 통합 세트를 제공하여 애플리케이션을 원활하게 업데이트합니다. 특히 IT 테스트 게이트를 통해 고객은 이미 AEM API를 사용하는 자체 테스트를 만들고 자동화할 수 있습니다.

사용자 지정 UI 테스트 기능은 고객이 애플리케이션에 대한 UI 테스트를 만들고 자동으로 실행할 수 있도록 해주는 선택적 기능 고객 옵트인 입니다. UI 테스트는 Java 및 Maven, Node 및 WebDriver.io와 같은 다양한 언어 및 프레임워크(또는 Selenium을 기반으로 구축된 기타 프레임워크 및 기술)를 사용할 수 있도록 Docker 이미지에 패키지된 Selenium 기반 테스트입니다. 여기에서 UI를 빌드하고 UI 테스트를 작성하는 방법에 대해 자세히 알아볼 수 있습니다. 또한 AEM Project Archetype을 사용하여 UI 테스트 프로젝트를 쉽게 생성할 수 있습니다.

고객은 GIT을 통해 사용자 지정 테스트를 만들고 UI용 테스트 세트를 만들 수 있습니다. UI 테스트는 각 Cloud Manager 파이프라인에 대한 특정 품질 게이트의 일부로서 특정 단계 및 피드백 정보와 함께 실행됩니다. 회귀 및 새로운 기능을 포함한 모든 UI 테스트를 통해 고객 컨텍스트 내에서 오류를 감지하고 보고할 수 있습니다.

고객 UI 테스트는 "사용자 지정 UI 테스트" 단계의 프로덕션 파이프라인에서 자동으로 실행됩니다.

Java로 작성된 HTTP 테스트인 사용자 지정 기능 테스트와 달리, UI 테스트는 UI 테스트 작성에 정의된 규칙을 따르는 한 모든 언어로 작성된 테스트가 있는 Docker 이미지가 될 수 있습니다.

고객 옵트인

UI 테스트를 빌드하고 실행하려면 고객이 코드 리포지토리에 파일을 추가하고(UI 테스트 하위 모듈의 pom.xml 파일 옆에 있는 UI 테스트용 maven 하위 모듈 아래) 이 파일을 빌드된 tar.gz 파일의 루트에 있는지 확인하여 "옵트인"해야 합니다.

파일 이름: testing.properties

내용: one line: ui-tests.version=1

기본 제공 tar.gz 파일에 없는 경우 UI 테스트 빌드 및 실행을 건너뜁니다

기능 테스트 쓰기

고객이 작성한 기능 테스트는 AEM에 배포할 아티팩트와 동일한 Maven 빌드에서 생성한 별도의 JAR 파일로 패키지해야 합니다. 일반적으로 이는 별도의 Maven 모듈입니다. 결과 JAR 파일은 필요한 모든 종속성을 포함해야 하며 일반적으로 jar-with-dependencies 설명자를 사용하여 maven-assembly-plugin을 사용하여 만듭니다.

또한 JAR에는 Cloud-Manager-TestType 매니페스트 헤더가 통합 테스트로 설정되어 있어야 합니다. 앞으로는 추가 헤더 값이 지원됩니다. maven-assembly-plugin에 대한 구성 예는 다음과 같습니다.

<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

이 JAR 파일 내에서 실행할 실제 테스트의 클래스 이름은 IT에서 끝나야 합니다.

예를 들어 com.myco.tests.aem.ExampleIT 라는 클래스가 실행되지만 com.myco.tests.aem.ExampleTest 라는 클래스는 실행되지 않습니다.

테스트 클래스는 일반적인 JUnit 테스트여야 합니다. 테스트 인프라는 aem-testing-clients 테스트 라이브러리에서 사용하는 규칙과 호환되도록 설계되고 구성됩니다. 개발자는 이 라이브러리를 사용하고 모범 사례를 따를 것을 적극 권장합니다. 자세한 내용은 Git 링크를 참조하십시오.

로컬 테스트 실행

테스트 클래스는 JUnit 테스트이므로 Eclipse, IntelliJ, NetBeans 등과 같은 메인스트림 Java IDE에서 실행할 수 있습니다.

그러나 이러한 테스트를 실행할 때에는 aem-testing-client(및 기본 Sling Testing Clients)에 의해 기대되는 다양한 시스템 속성을 설정해야 합니다.

시스템 속성은 다음과 같습니다.

• sling.it.instances - should be set to 2
• sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
• sling.it.instance.runmode.1 - should be set to author
• sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
• sling.it.instance.adminPassword.1 - should be set to the author admin password
• sling.it.instance.url.2 - should be set to the author URL, for example, http://localhost:4503
• sling.it.instance.runmode.2 - should be set to publish
• sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
• sling.it.instance.adminPassword.2 - should be set to the publish admin password