Test di unità unit-testing

Controlla il ramo tutorial/unit-testing-start da GitHub

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

Implementa la base di codice in un’istanza AEM locale utilizzando le tue competenze Maven:

$ mvn clean install -PautoInstallSinglePackage

$ mvn clean install -PautoInstallSinglePackage -Pclassic

Per visualizzare queste dipendenze, apri il POM Reactor padre all'indirizzo aem-guides-wknd/pom.xml, passa a <dependencies>..</dependencies> e visualizza le dipendenze per JUnit, Mockito, Apache Sling Mocks e AEM Mock Test di io.wcm in <!-- Testing -->.

Verificare che io.wcm.testing.aem-mock.junit5 sia impostato su 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>

Apri aem-guides-wknd/core/pom.xml e osserva che le dipendenze di test corrispondenti sono disponibili.

Una cartella di origine parallela nel progetto core conterrà gli unit test ed eventuali file di test di supporto. Questa cartella test fornisce la separazione delle classi di test dal codice sorgente, ma consente ai test di agire come se si trovassero negli stessi pacchetti del codice sorgente.

Creare uno unit test per BylineImpl.java creando una nuova classe Java™ in src/test/java in una struttura di cartelle di pacchetti Java™ che rispecchia la posizione della classe Java™ da testare.

Poiché stiamo testando

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

crea una classe Java™ unit test corrispondente in

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

Il suffisso Test nel file di unit test BylineImplTest.java è una convenzione che consente di

1. Identificarlo facilmente come file di test per BylineImpl.java
2. Ma anche differenziare il file di test da la classe in fase di test, BylineImpl.java

Aggiorna il file con il seguente codice:

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

Il primo metodo public void setUp() { .. } è annotato con JUnit @BeforeEach, che indica al runner di test JUnit di eseguire questo metodo prima di eseguire ogni metodo di test in questa classe. In questo modo è possibile inizializzare lo stato di test comune richiesto da tutti i test.

I metodi successivi sono i metodi di test, i cui nomi sono preceduti da test per convenzione e contrassegnati con l'annotazione @Test. Per impostazione predefinita, tutti i nostri test sono impostati per non riuscire, poiché non li abbiamo ancora implementati.

Per iniziare, iniziamo con un singolo metodo di test per ogni metodo pubblico sulla classe che stiamo testando, quindi:

Questi metodi possono essere ampliati in base alle esigenze, come vedremo più avanti in questo capitolo.

Quando viene eseguita questa classe di test JUnit (nota anche come test case JUnit), ogni metodo contrassegnato con @Test verrà eseguito come test che può essere superato o non superato.

Eseguire il test case JUnit facendo clic con il pulsante destro del mouse sul file BylineImplTest.java e toccando Esegui.
Come previsto, tutti i test hanno esito negativo poiché non sono ancora stati implementati.

Fare clic con il pulsante destro del mouse su BylineImplTests.java > Esegui

Creare un contesto AEM utilizzando wcm.io's AemContext in BylineImplTest.java aggiungendolo come estensione JUnit decorata con @ExtendWith al file BylineImplTest.java. L'estensione si occupa di tutte le attività di inizializzazione e pulizia necessarie. Creare una variabile di classe per AemContext che può essere utilizzata per tutti i metodi di 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();

Questa variabile, ctx, espone un contesto AEM fittizio che fornisce alcune astrazioni AEM e Sling:

• Il modello Sling BylineImpl è registrato in questo contesto
• In questo contesto vengono create strutture di contenuto JCR fittizie
• I servizi OSGi personalizzati possono essere registrati in questo contesto
• Fornisce vari oggetti fittizi e helper comuni richiesti, come oggetti SlingHttpServletRequest, vari servizi fittizi Sling e AEM OSGi come ModelFactory, PageManager, Page, Template, ComponentManager, Component, TagManager, Tag, ecc.
  • Non tutti i metodi per questi oggetti sono implementati!
• E molto di più!

L'oggetto ctx fungerà da punto di ingresso per la maggior parte del contesto fittizio.

Nel metodo setUp(..), eseguito prima di ogni metodo @Test, definire uno stato di test fittizio comune:

@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 registra il modello Sling da testare nel contesto AEM fittizio, in modo da crearne un'istanza nei metodi @Test.
• load().json carica le strutture delle risorse nel contesto fittizio, consentendo al codice di interagire con tali risorse come se fossero fornite da un archivio reale. Le definizioni delle risorse nel file BylineImplTest.json sono caricate nel contesto JCR fittizio in /content.
• BylineImplTest.json non esiste ancora, quindi creiamolo e definiamo le strutture di risorse JCR necessarie per il test.

I file JSON che rappresentano le strutture di risorse fittizie sono archiviati in core/src/test/resources seguendo lo stesso percorso del pacchetto del file di test Java™ JUnit.

Crea un file JSON in core/test/resources/com/adobe/aem/guides/wknd/core/models/impl denominato BylineImplTest.json con il seguente contenuto:

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

Questo JSON definisce una risorsa fittizia (nodo JCR) per l’unit test del componente Byline. A questo punto, il JSON ha il set minimo di proprietà necessarie per rappresentare una risorsa di contenuto del componente Byline, jcr:primaryType e sling:resourceType.

Una regola generale quando si lavora con gli unit test consiste nel creare il set minimo di contenuti fittizi, contesto e codice necessario per soddisfare ogni test. Evita la tentazione di creare un contesto fittizio completo prima di scrivere i test, in quanto spesso genera artefatti non necessari.

Ora con l'esistenza di BylineImplTest.json, quando viene eseguito ctx.json("/com/adobe/aem/guides/wknd/core/models/impl/BylineImplTest.json", "/content"), le definizioni delle risorse fittizie vengono caricate nel contesto nel percorso /contenuto.

Aggiornare il metodo testGetName() in BylineImplTest.java come segue:

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 imposta il valore previsto. Verrà impostato su "Jane Done".
• ctx.currentResource imposta il contesto della risorsa fittizia su cui valutare il codice, quindi viene impostato su /content/byline in quanto è dove viene caricata la risorsa di contenuto fittizia.
• Byline byline crea un'istanza del modello Sling Byline adattandolo dal finto oggetto Request.
• String actual richiama il metodo in fase di test, getName(), sull'oggetto modello Sling Byline.
• assertEquals asserisce che il valore previsto corrisponde al valore restituito dall'oggetto modello Sling byline. Se questi valori non sono uguali, il test avrà esito negativo.

Esegui il test… e non riesce con NullPointerException.

Il test NON ha esito negativo perché non è mai stata definita una proprietà name nel JSON fittizio. Il test non verrà eseguito correttamente, tuttavia l'esecuzione del test non è arrivata a questo punto. Il test non riesce a causa di un NullPointerException nell'oggetto byline stesso.

In BylineImpl.java, se @PostConstruct init() genera un'eccezione, impedisce al modello Sling di creare un'istanza e causa l'impostazione dell'oggetto modello Sling come null.

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

Si è verificato che mentre il servizio OSGi ModelFactory viene fornito tramite AemContext (tramite il contesto Sling Apache), non tutti i metodi vengono implementati, incluso getModelFromWrappedRequest(...) che viene chiamato nel metodo init() di BylineImpl. Ciò determina un AbstractMethodError, che nel termine causa il mancato funzionamento di init() e l'adattamento risultante di ctx.request().adaptTo(Byline.class) è un oggetto null.

Poiché gli scherzi forniti non possono contenere il nostro codice, è necessario implementare direttamente il contesto fittizio. Per questo è possibile utilizzare Mockito per creare un oggetto ModelFactory fittizio, che restituisce un oggetto Image fittizio quando getModelFromWrappedRequest(...) viene richiamato su di esso.

Poiché per creare un'istanza del modello Sling Byline è necessario che il contesto fittizio sia attivo, è possibile aggiungerlo al metodo @Before setUp(). È inoltre necessario aggiungere MockitoExtension.class all'annotazione @ExtendWith sopra 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}) contrassegna la classe Test Case da eseguire con l'estensione Mockito JUnit Jupiter che consente l'utilizzo delle annotazioni @Mock per definire oggetti fittizi a livello di classe.
• @Mock private Image crea un oggetto fittizio di tipo com.adobe.cq.wcm.core.components.models.Image. Viene definito a livello di classe in modo che, se necessario, i metodi @Test possano modificarne il comportamento in base alle esigenze.
• @Mock private ModelFactory crea un oggetto fittizio di tipo ModelFactory. Questa è una pura beffa di Mockito e non ha metodi implementati su di essa. Questo viene definito a livello di classe in modo che, se necessario, @Test metodi possano modificarne il comportamento in base alle esigenze.
• when(modelFactory.getModelFromWrappedRequest(..) registra il comportamento fittizio per quando getModelFromWrappedRequest(..) viene chiamato sull'oggetto ModelFactory fittizio. Il risultato definito in thenReturn (..) è quello di restituire l'oggetto immagine fittizio. Questo comportamento viene richiamato solo quando: il primo parametro è uguale all'oggetto di richiesta di ctx, il secondo parametro è qualsiasi oggetto Resource e il terzo parametro deve essere la classe Immagine dei Componenti core. Accettiamo qualsiasi risorsa perché durante i test impostiamo ctx.currentResource(...) su varie risorse fittizie definite in BylineImplTest.json. Si noti che verrà aggiunta la rigidità lenient() perché in seguito si desidera ignorare questo comportamento di ModelFactory.
• ctx.registerService(..). registra l'oggetto ModelFactory fittizio in AemContext, con la classificazione di servizio più elevata. Questa operazione è necessaria perché ModelFactory utilizzato in init() di BylineImpl viene inserito tramite il campo @OSGiService ModelFactory model. Affinché AemContext inserisca l'oggetto fittizio our, che gestisce le chiamate a getModelFromWrappedRequest(..), è necessario registrarlo come servizio di classificazione più elevata di quel tipo (ModelFactory).

Riesegui il test e di nuovo non riesce, ma questa volta il messaggio indica chiaramente il motivo dell’errore.

errore testGetName() a causa di un'asserzione

Riceviamo un AssertionError che indica che la condizione di asserzione nel test non è riuscita e ci dice che il valore previsto è "Jane Doe" ma il valore effettivo è nullo. Ciò ha senso perché la proprietà "name" non è stata aggiunta alla definizione fittizia della risorsa /content/byline in BylineImplTest.json, quindi aggiungiamola:

Aggiorna BylineImplTest.json per definire "name": "Jane Doe".

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

Riesegui il test e testGetName() ora supera il test.

Aggiorna testGetOccupations() come segue:

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 definiscono il risultato previsto.
• ctx.currentResource imposta la risorsa corrente per la valutazione del contesto sulla definizione di risorsa fittizia in /content/byline. In questo modo BylineImpl.java viene eseguito nel contesto della risorsa fittizia.
• ctx.request().adaptTo(Byline.class) crea un'istanza del modello Sling Byline adattandolo dal finto oggetto Request.
• byline.getOccupations() richiama il metodo in fase di test, getOccupations(), sull'oggetto modello Sling Byline.
• assertEquals(expected, actual) asserisce che l'elenco previsto è uguale all'elenco effettivo.

Ricorda che, proprio come getName() in precedenza, BylineImplTest.json non definisce le occupazioni, pertanto questo test non riuscirà se viene eseguito, poiché byline.getOccupations() restituirà un elenco vuoto.

Aggiorna BylineImplTest.json per includere un elenco di occupazioni impostate in ordine non alfabetico per garantire che i test convalidi che le occupazioni siano ordinate alfabeticamente per getOccupations().

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

Esegui il test e passiamo di nuovo! Sembra che le occupazioni ordinate funzionino!

testGetOccupations() passa

Il primo test verifica la condizione di un componente nuovo, che non ha proprietà impostate.

Aggiungi una nuova definizione di risorsa a BylineImplTest.json, assegnandole il nome semantico "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": {...} definiscono una nuova definizione di risorsa denominata "empty" che ha solo jcr:primaryType e sling:resourceType.

Ricorda che abbiamo caricato BylineImplTest.json in ctx prima dell'esecuzione di ogni metodo di test in @setUp, quindi questa nuova definizione di risorsa è immediatamente disponibile nei test in /content/empty.

Aggiornare testIsEmpty() come segue, impostando la risorsa corrente sulla nuova definizione di risorsa fittizia "empty".

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

    assertTrue(byline.isEmpty());
}

Esegui il test e assicurati che venga superato.

Creare quindi un set di metodi per garantire che, se uno qualsiasi dei punti di dati richiesti (nome, occupazioni o immagine) è vuoto, isEmpty() restituisca true.

Per ogni test viene utilizzata una definizione di risorsa fittizia discreta. Aggiornare BylineImplTest.json con le definizioni di risorsa aggiuntive per without-name e 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"
    }
}

Crea i seguenti metodi di test per testare ciascuno di questi stati.

@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() verifica la definizione della risorsa fittizia vuota e asserisce che isEmpty() è true.

testIsEmpty_WithoutName() esegue il test in base a una definizione di risorsa fittizia con occupazioni ma senza nome.

testIsEmpty_WithoutOccupations() esegue il test in base a una definizione di risorsa fittizia con un nome ma senza occupazioni.

testIsEmpty_WithoutImage() esegue il test in base a una definizione di risorsa fittizia con un nome e occupazioni, ma imposta l'immagine fittizia su null. Si noti che si desidera ignorare il comportamento modelFactory.getModelFromWrappedRequest(..) definito in setUp() per assicurarsi che l'oggetto Image restituito da questa chiamata sia nullo. La funzione Mockito stubs è rigida e non richiede codice duplicato. Pertanto, abbiamo impostato le impostazioni del simulatore con lenient in modo che notino esplicitamente che stiamo ignorando il comportamento nel metodo setUp().

testIsEmpty_WithoutImageSrc() esegue test su una definizione di risorsa fittizia con un nome e occupazioni, ma imposta l'immagine fittizia in modo che restituisca una stringa vuota quando viene richiamato getSrc().

Infine, scrivere un test per assicurarsi che isEmpty() restituisca false quando il componente è configurato correttamente. Per questa condizione, è possibile riutilizzare /content/byline che rappresenta un componente Byline completamente configurato.

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

Ora esegui tutti gli unit test nel file BylineImplTest.java e controlla l’output del rapporto sui test Java™.