Test unitaire unit-testing

Consultez la branche tutorial/unit-testing-start à partir de GitHub.

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

Déployez la base de code sur une instance locale d’AEM à l’aide de vos compétences Maven :

$ mvn clean install -PautoInstallSinglePackage

$ mvn clean install -PautoInstallSinglePackage -Pclassic

Pour afficher ces dépendances, ouvrez le fichier POM Reactor parent sur aem-guides-wknd/pom.xml, accédez aux <dependencies>..</dependencies> et affichez les dépendances de JUnit, de Mockito, des simulations Sling d’Apache et des tests de simulation d’AEM par io.wcm sous <!-- Testing -->.

Assurez-vous que io.wcm.testing.aem-mock.junit5 est défini sur 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>

Ouvrez aem-guides-wknd/core/pom.xml et vérifiez que les dépendances de test correspondantes sont disponibles.

Un dossier source parallèle dans le projet principal contiendra les tests unitaires et tous les fichiers de test annexes. Ce dossier de test offre une séparation entre les classes de test et le code source, mais permet aux tests d’agir comme s’ils résidaient dans les mêmes packages que le code source.

Créez un test unitaire pour BylineImpl.java en créant une nouvelle classe Java™ sous src/test/java dans une structure de dossiers de package Java™ qui reflète l’emplacement de la classe Java™ à tester.

Puisque nous testons

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

créez une classe Java™ de test unitaire correspondante à

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

Le suffixe Test sur le fichier de test unitaire, BylineImplTest.java, est une convention, qui nous permet de

1. facilement l’identifier comme fichier de test pour BylineImpl.java
2. mais aussi de différencier le fichier de test de la classe en cours de test, BylineImpl.java.

Mettez à jour le fichier avec le code suivant :

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");
    }
}

La première méthode public void setUp() { .. } est annotée avec la fonction @BeforeEach de JUnit qui indique à l’exécuteur de test JUnit d’exécuter cette méthode avant l’exécution de chaque méthode de test de cette classe. Vous bénéficiez ainsi d’un emplacement pratique pour initialiser l’état de test commun requis par tous les tests.

Les méthodes suivantes sont les méthodes de test dont les noms comportent par convention le préfixe test et qui sont marquées avec l’annotation @Test. Notez que, par défaut, tous nos tests sont définis pour échouer, car nous ne les avons pas encore implémentés.

Pour commencer, nous utilisons une méthode de test unique pour chaque méthode publique sur la classe que nous testons, de sorte que :

Ces méthodes peuvent être développées au besoin, comme nous le verrons plus loin dans ce chapitre.

Lorsque cette classe de test JUnit (également appelée cas de test JUnit) est exécutée, chaque méthode marquée par @Test s’exécute en tant que test pouvant réussir ou échouer.

Exécutez le cas de test JUnit en cliquant avec le bouton droit sur le fichier BylineImplTest.java et en appuyant sur Exécuter.
Comme prévu, tous les tests échouent, car ils n’ont pas encore été implémentés.

Cliquez avec le bouton droit sur BylineImplTests.java > Exécuter.

Créez un contexte AEM à l’aide de AemContext de wcm.io dans BylineImplTest.java en l’ajoutant en tant qu’extension JUnit décorée avec @ExtendWith au fichier BylineImplTest.java. L’extension se charge de toutes les tâches d’initialisation et de nettoyage obligatoires. Créez une variable de classe pour AemContext qui peut être utilisée pour toutes les méthodes de test.

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();

Cette variable, ctx, expose un contexte AEM simulé qui fournit certaines abstraction d’AEM et Sling :

• Le modèle Sling BylineImpl est enregistré dans ce contexte.
• Les structures de contenu JCR simulées sont créées dans ce contexte.
• Les services OSGi personnalisés peuvent être enregistrés dans ce contexte.
• Elle fournit divers assistants et objets simulés, comme les objets SlingHttpServletRequest, et plusieurs services simulés Sling et OSGi d’AEM tels que ModelFactory, PageManager, Page, Modèle, ComponentManager, Composant, TagManager, Balise, etc.
  • Toutes les méthodes de ces objets ne sont pas implémentées.
• Et bien plus encore.

L’objet ctx agit comme point d’entrée pour la plupart du contexte simulé.

Dans la méthode setUp(..), qui est exécutée avant chaque méthode @Test, définissez un état de test simulé courant :

@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 enregistre le modèle Sling à tester, dans le contexte AEM simulé, afin qu’il puisse être instancié dans les méthodes @Test.
• load().json charge les structures de ressources dans le contexte simulé, ce qui permet au code d’interagir avec ces ressources comme si elles étaient fournies par un référentiel réel. Les définitions des ressources du fichier BylineImplTest.json sont chargées dans le contexte JCR simulé sous /content.
• BylineImplTest.json n’existe pas encore. Créons-le donc et définissons les structures de ressources JCR nécessaires au test.

Les fichiers JSON représentant les structures de ressources simulées sont stockés sous core/src/test/resources suivant le même cheminement de package que le fichier de test JUnit Java™.

Créez un fichier JSON dans core/test/resources/com/adobe/aem/guides/wknd/core/models/impl appelé BylineImplTest.json avec le contenu suivant :

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

Ce JSON définit une ressource simulée (nœud JCR) pour le test unitaire du composant de signature. À ce stade, le fichier JSON dispose de l’ensemble minimum de propriétés requises pour représenter une ressource de contenu de composant de signature, le jcr:primaryType et le sling:resourceType.

Lors de l’utilisation de tests unitaires, une règle générale consiste à créer l’ensemble minimal de contenu simulé, de contexte et de code requis pour satisfaire chaque test. Ne cédez pas à la tentation de créer un contexte simulé complet avant d’écrire les tests, car cela génère souvent des artefacts inutiles.

Maintenant que BylineImplTest.json existe, lors de l’exécution de ctx.json("/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.json", "/content"), les définitions de ressources simulées sont chargées dans le contexte au niveau du chemin d’accès /content.

Mettez à jour la méthode testGetName() dans BylineImplTest.java comme suit :

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 définit la valeur attendue. Nous définirons cette valeur sur «  Jane Doe  ».
• ctx.currentResource définit le contexte de la ressource simulée pour évaluer le code ; cela est donc défini sur /content/byline car c’est là que la ressource de contenu de signature simulée est chargée.
• Byline byline instancie le modèle Sling de signature en l’adaptant à partir de l’objet de requête simulée.
• String actual appelle la méthode que nous testons, getName(), sur l’objet de modèle Sling de signature.
• assertEquals déclare que la valeur attendue correspond à la valeur renvoyée par l’objet de modèle Sling de signature. Si ces valeurs ne sont pas égales, le test échoue.

Exécutez le test. Il échoue avec une exception NullPointerException.

L’échec de ce test n’est PAS dû au fait que nous n’avons jamais défini une propriété name dans le JSON simulé qui provoque l’échec du test, car l’exécution du test n’a pas atteint ce point. Ce test échoue en raison d’une exception NullPointerException sur l’objet de signature lui-même.

Dans BylineImpl.java, si la méthode @PostConstruct init() renvoie une exception, elle empêche l’instantiation du modèle Sling ; cet objet de modèle Sling devient alors null.

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

Il s’avère que, tandis que le service OSGi ModelFactory est fourni via AemContext (au moyen du contexte Sling d’Apache), toutes les méthodes ne sont pas implémentées, y compris getModelFromWrappedRequest(...) qui est appelée dans la méthode init() de BylineImpl. Cela entraîne une erreur AbstractMethodError, qui à terme provoque l’échec de init(). L’adaptation obtenue de ctx.request().adaptTo(Byline.class) est un objet null.

Comme les simulations fournies ne peuvent pas prendre en charge notre code, nous devons implémenter le contexte simulé nous-mêmes. Pour cela, nous pouvons utiliser Mockito pour créer un objet ModelFactory simulé, qui renvoie un objet Image simulé quand la méthode getModelFromWrappedRequest(...) est appelée dessus.

Puisque ce contexte simulé doit être en place pour instancier le modèle Sling de signature, nous pouvons l’ajouter à la méthode @Before setUp(). Nous devons également ajouter MockitoExtension.class à l’annotation @ExtendWith au-dessus de la classe BylineImplTest.

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}) marque la classe de cas de test à exécuter avec l’extension Jupiter JUnit de Mockito qui permet l’utilisation des annotations @Mock pour définir des objets simulés au niveau de la classe.
• @Mock private Image crée un objet simulé de type com.adobe.cq.wcm.core.components.models.Image. Il est défini au niveau de la classe de sorte que, si nécessaire, les méthodes @Test peuvent modifier son comportement au besoin.
• @Mock private ModelFactory crée un objet simulé de type ModelFactory. Il s’agit d’une pure simulation de Mockito qui ne comporte aucune méthode implémentée. Elle est définie au niveau de la classe de sorte que, si nécessaire, les @Test peuvent modifier son comportement au besoin.
• when(modelFactory.getModelFromWrappedRequest(..) enregistre le comportement simulé pour le moment où la méthode getModelFromWrappedRequest(..) est appelée sur l’objet simulé ModelFactory. Le résultat défini dans thenReturn (..) permet de renvoyer l’objet Image simulé. Ce comportement est uniquement invoqué si : le premier paramètre est égal à l’objet de requête du ctx, le deuxième paramètre est un objet d’une ressource quelconque, et le troisième paramètre doit être la classe d’image des composants principaux. Nous acceptons n’importe quelle ressource car tout au long de nos tests, nous paramétrons la ctx.currentResource(...) sur différentes ressources fictives définies dans BylineImplTest.json. Notez que nous ajoutons le niveau de rigueur lenient(), car nous voulons par la suite remplacer ce comportement de ModelFactory.
• ctx.registerService(..). enregistre l’objet simulé ModelFactory dans AemContext, avec le rang de service le plus élevé. Cela est obligatoire, car le ModelFactory utilisé dans le init() de BylineImpl’s est injecté via le champ @OSGiService ModelFactory model. Pour qu’AemContext s’injecte dans notre objet simulé, qui gère les appels sur getModelFromWrappedRequest(..), nous devons l’enregistrer avec le rang de service le plus élevé de ce type (ModelFactory).

Relancez le test. Il échoue à nouveau, mais cette fois, le message est clair et explique pourquoi il a échoué.

Échec de testGetName() en raison de l’assertion

Nous recevons une AssertionError, ce qui signifie que la condition d’assertion dans le test a échoué, et on nous indique que la valeur attendue est « Jane Doe » mais que la valeur réelle est null. Cela est logique, car la propriété « nom » n’a pas été ajoutée à la définition de ressource /content/byline simulée dans BylineImplTest.json, alors ajoutons-la :

Mettez à jour BylineImplTest.json pour définir "name": "Jane Doe"..

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

Réexécutez le test, et le testGetName() est maintenant un succès.

Mettez à jour testGetOccupations() comme suit :

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 définit le résultat attendu.
• ctx.currentResource définit la ressource actuelle pour évaluer le contexte par rapport à la définition de la ressource simulée à l’emplacement /content/byline. Cela permet de s’assurer que BylineImpl.java s’exécute dans le contexte de notre ressource simulée.
• ctx.request().adaptTo(Byline.class) instancie le modèle Sling de signature en l’adaptant à partir de l’objet de requête simulée.
• byline.getOccupations() appelle la méthode que nous testons, getOccupations(), sur l’objet de modèle Sling de signature.
• assertEquals(expected, actual) affirme que la liste attendue est la même que la liste réelle.

Rappelez-vous, tout comme getName() ci-dessus, le fichier BylineImplTest.json ne définit pas les professions, ce test échouera donc si nous l’exécutons, puisque byline.getOccupations() renverra une liste vide.

Mettez à jour BylineImplTest.json pour inclure une liste de professions. Ces dernières sont placées dans un ordre non alphabétique pour que nos tests puissent confirmer que les professions sont triées par ordre alphabétique par getOccupations().

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

Exécutez le test, et encore une fois nous avons réussi. Il semblerait que le tri des professions fonctionne.

Le testGetOccupations() réussit.

Le premier test porte sur l’état d’un tout nouveau composant qui n’a pas de propriétés définies.

Ajoutez une nouvelle définition de ressource à BylineImplTest.json, en lui donnant le nom sémantique «  vide  ».

{
    "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": {...} définit une nouvelle définition de ressource nommée « vide » qui ne comporte qu’un jcr:primaryType et un sling:resourceType.

Rappelez-vous que nous chargeons BylineImplTest.json dans ctx avant l’exécution des méthodes de test dans @setUp. Cette nouvelle définition de ressource est donc immédiatement disponible pour nous dans les tests à /content/empty..

Mettez à jour testIsEmpty() comme suit, en choisissant la nouvelle définition de ressource simulée «  vide  ».

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

    assertTrue(byline.isEmpty());
}

Exécutez le test et vérifiez qu’il réussit.

Créez ensuite un ensemble de méthodes pour vous assurer que si l’un des points de données requis (nom, profession ou image) est vide, isEmpty() renvoie « true ».

Pour chaque test, une définition de ressource simulée discrète est utilisée. Mettez à jour BylineImplTest.json avec les définitions de ressources supplémentaires pour without-name et without-occupations.

{
    "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"
    }
}

Créez les méthodes de test suivantes pour tester chacun de ces états.

@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() teste la définition de la ressource simulée vide et affirme que isEmpty() est « true ».

testIsEmpty_WithoutName() teste une définition de ressource simulée qui a des professions mais pas de nom.

testIsEmpty_WithoutOccupations() teste une définition de ressource simulée qui a un nom mais pas de profession.

testIsEmpty_WithoutImage() teste une définition de ressource simulée avec un nom et des professions, mais définit l’image simulée sur null. Notez que nous voulons remplacer le comportement de modelFactory.getModelFromWrappedRequest(..) défini dans setUp() pour nous assurer que l’objet Image renvoyé par cet appel est null. La fonction de bouchon Mockito est stricte et refuse le code dupliqué. Par conséquent, nous définissons la simulation avec des paramètres lenient pour indiquer explicitement que nous remplaçons le comportement dans la méthode setUp().

testIsEmpty_WithoutImageSrc() teste une définition de ressource simulée avec un nom et des professions, mais définit l’image simulée de sorte qu’elle renvoie une chaîne vide lorsque la fonction getSrc() est appelée.

Enfin, écrivez un test pour vous assurer que la fonction isEmpty() renvoie « false » lorsque le composant est correctement configuré. Pour cette condition, nous pouvons réutiliser /content/byline qui représente un composant de signature entièrement configuré.

@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());
}

Exécutez maintenant tous les tests unitaires dans le fichier BylineImplTest.java et passez en revue la sortie du rapport de test Java™.