単体テスト 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

これらの依存関係を表示するには、親リアクター POM（aem-guides-wknd/pom.xml）を開いて <dependencies>..</dependencies> に移動すると、<!-- Testing --> の下で JUnit、Mockito、Apache Sling Mocks、AEM Mock Tests（io.wcm から提供）の依存関係を確認できます。

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 を開き、対応するテストの依存関係が使用可能であることを確認します。

コア ​プロジェクトの並列ソースフォルダーには、単体テストと、サポートするテストファイルが含まれます。この 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. テストファイルとして容易に識別できます 対象 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 の注釈でマークされた名前のテストメソッドです。 まだ実装されていないため、デフォルトですべてのテストが失敗するように設定されています。

まず、テストするクラスのパブリックメソッドごとに 1 つのテストメソッドから始めます。そのため、次のようにします。

これらのメソッドは必要に応じて拡張できます。詳しくはこの章で後述します。

この JUnit テストクラス（別称：JUniit テストケース）が実行されている場合、@Test とマークされた各メソッドは、成功または失敗する可能性があるテストとして実行されます。

JUnit テストケースを実行するには、 BylineImplTest.java ファイルを右クリックして「実行」をタップ します。
まだ実装されていないので、予想どおりすべてのテストが失敗します。

BylineImplTests.java／実行を右クリックします。

BylineImplTest.java で wcm.io の AemContextを使用して、@ExtendWith でデコレートされた JUnit 拡張機能として BylineImplTest.java ファイルに追加することで、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 オブジェクトなど）、様々なモック Sling および AEM OSGi サービス（ModelFactory、PageManager、ページ、テンプレート、ComponentManager、コンポーネント、TagManager、タグなど）を提供します。
  • これらのオブジェクトのすべてのメソッドが実装されるわけではありません。
• その他

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 に保存されます。

次の内容を含んだ BylineImplTest.json という名前の JSON ファイルを core/test/resources/com/adobe/aem/guides/wknd/core/models/impl に作成します。

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

この JSON は、署名コンポーネントの単体テストのモックリソース（JCR ノード）を定義します。この時点で、JSON には署名コンポーネントのコンテンツリソースを表すのに必要なプロパティの最小セットである 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 は、コードを評価する際に対照とするモックリソースのコンテキストを設定します。そのため、これはモック署名コンテンツリソースの読み込み先となる /content/byline に設定されます。
• Byline byline は、モックリクエストオブジェクトから適応させて、署名 Sling モデルをインスタンス化します。
• String actual は、署名 Sling モデルオブジェクト上で、テスト対象であるメソッド getName() を呼び出します。
• assertEquals は、想定される値が、署名 Sling モデルオブジェクトから返される値と一致するとアサートします。これらの値が等しくない場合、テストは失敗します。

テストを実行しますが、NullPointerException で失敗します。

モック JSON で name プロパティを定義していないからといって、このテストが失敗するわけではありません。モック JSON はテスト失敗の原因になりますが、このテストはまだそこまで実行されていません。このテストは、署名オブジェクト自体での 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 を使用して、getModelFromWrappedRequest(...) が呼び出されたときにモック Image オブジェクトを返すモック ModelFactory オブジェクトを作成します。

署名 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}) は、テストケースクラスを Mockito JUnit Jupiter 拡張機能で実行するようにマークし、@Mock 注釈を使用してモックオブジェクトをクラスレベルで定義できるようにします。
• @Mock private Image はタイプ com.adobe.cq.wcm.core.components.models.Image のモックオブジェクトを作成します。これはクラスレベルで定義されているので、必要に応じて、@Test メソッドで動作を変更できます。
• @Mock private ModelFactory は ModelFactory タイプのモックオブジェクトを作成します。これは純粋な Mockito モックであり、実装されているメソッドはありません。これはクラスレベルで定義されているので、必要に応じて、@Test メソッドで動作を変更できます。
• when(modelFactory.getModelFromWrappedRequest(..) は、モック ModelFactory オブジェクトで getModelFromWrappedRequest(..) が呼び出された場合のモック動作を登録します。thenReturn (..) に定義されている結果は、モック Image オブジェクトを返すことです。この動作が呼び出されるのは、最初のパラメータが ctx のリクエストオブジェクトと等しく、2 番目のパラメータが任意の Resource オブジェクトであり、3 番目のパラメータがコアコンポーネントの Image クラスである場合のみです。テスト全体を通して、ctx.currentResource(...) を BylineImplTest.json で定義されている様々なモックリソースに設定しているので、どのような Resource でも使用できます。なお、後で ModelFactory の該当する動作をオーバーライドする必要があるので、lenient() の厳密性を追加します。
• ctx.registerService(..)。 は、モック ModelFactory オブジェクトを最高のサービスランキングで AemContext に登録します。BylineImpl の init() で使用される ModelFactory は @OSGiService ModelFactory model フィールドを通じて挿入されるので、これが必要になります。AemContext で getModelFromWrappedRequest(..) への呼び出しを処理する​ 今回の ​モックオブジェクトを挿入するには、そのタイプ（ModelFactory）の最もランキングの高いサービスとして登録する必要があります。

テストを再度実行すると再び失敗しますが、今回は失敗の理由は明白です。

アサーションによる testGetName() の失敗

AssertionError が返されます。これはテストでのアサート条件が失敗し、期待値は "Jane Doe" で、実際の値が null であることを示します。BylineImplTest.json のモック​ /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 Model をモックリクエストオブジェクトから適応させてインスタンス化します。
• byline.getOccupations() ​は署名 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"]
    }
}

テストを実行すると、再び合格です。職業の並べ替えが正常に機能しているようです。

testGetOccupations() は成功

最初のテストは、プロパティが設定されていない、まったく新しいコンポーネントの条件をテストします。

BylineImplTest.json に新しいリソース定義を追加し、意味のある名前「empty」を付けます。

{
    "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() を次のように更新し、現在のリソースを新しい「empty」というモックリソース定義に設定します。

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

    assertTrue(byline.isEmpty());
}

テストを実行し、成功することを確認します。

次に、必要なデータポイント（名前、職業、または画像）が空の場合、isEmpty() が true を返すメソッドのセットを作成します。

各テストで、個別のモックリソース定義が使用され、without-name および without-occupations の追加リソース定義を使用して 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 を返すよう設定します。なお、setUp() で定義された動作 modelFactory.getModelFromWrappedRequest(..) をオーバーライドして、この呼び出しによって返される画像オブジェクトが null になるようにします。 Mockito のスタブ機能は厳密なため、コードの重複は避けます。 したがって、lenient 設定を使用してモックを設定し、setUp() メソッドでの動作をオーバーライドすることを明示的に示します。

testIsEmpty_WithoutImageSrc() は、名前と職業でモックリソース定義をテストし、getSrc() を呼び出すと空白の文字列を返すようモック画像を設定します。

最後に、コンポーネントが正しく設定されている場合、isEmpty() が false を返すようテストを記述します。この条件の場合は、完全に設定された署名コンポーネントを表す /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™ テストレポートの出力を確認します。