Panoramica

Nell'articolo precedente , ho definito "Unit Testing" e come possiamo applicare questi test alla nostra applicazione Angular. Siamo d'accordo che, per definizione, la nostra logica di business dovrebbe vivere al di fuori dei nostri componenti e la maggior parte delle nostre funzionalità risiederà in pipe, direttive e servizi, il che significa che la maggior parte dei nostri unit test testerà quei tipi di classi. In quell'articolo, ho anche pubblicato un riassunto di un componente Angular con la sua logica di template spostata dal componente in una pipe, lasciando solo una Input()definizione nella classe e alcuni template. Siamo tutti d'accordo sul fatto che, in qualsiasi momento, qualcuno potrebbe entrare e aggiungere o rimuovere elementi nell'elemento, e non ci sono test unitari che potrebbero catturare quei cambiamenti.

Quindi, se non puoi utilizzare i test unitari per testare correttamente un componente, ti rimane solo il componente, l'integrazione o il test end-to-end.

Il test di integrazione potrebbe funzionare, ma per definizione, il test di integrazione si verifica quando si testano singole unità e le si combinano per testare come gruppo. Quindi, ad esempio, potresti provare ComponentAcon ComponentB, e probabilmente in alcuni casi va bene. Ma cosa succede quando ti integri ComponentAcon ComponentC? Ti senti a tuo agio nel dire che il primo test che hai creato è abbastanza buono per spedire il tuo prodotto alla produzione?

Secondo i documenti Angular :

Gli elementi costitutivi di base del framework Angular sono i componenti Angular...

I componenti sono progettati per essere combinati e utilizzati da diversi componenti per creare la tua applicazione. Pertanto, devi essere in grado di assicurarti di avere una fonte di verità per il DOM, in particolare le tue caratteristiche Inpute Outputproprietà di accessibilità e qualsiasi stile che ritieni pertinente per assicurarti che sia sempre valido e che non avresti bisogno di testare manualmente.

Torniamo al componente Header:

A prima vista, non c'è molto da testare . In un mondo ideale, sapremmo che NameDisplayPipedispone di test che convalidano i valori forniti dal componente e restituiscono ciò che ci aspettiamo. Ma cosa succede se qualcuno modifica accidentalmente il h1carattere h2? Cosa succede se qualcuno rimuove accidentalmente l'inizializzazione del titolo?

Test dei componenti in soccorso

Il test dei componenti è incredibile poiché elimina la necessità di testare manualmente molte cose a cui siamo abituati a testare manualmente. Ad esempio, conosco solo pochi sviluppatori che pensano di definire la struttura del template del componente (la parte più cruciale) attraverso dei test; tuttavia, conosco molti QA e designer che controllano manualmente queste cose. Tuttavia, è qualcosa di cui generalmente non discutiamo. Siamo fermamente convinti di testare le nostre funzionalità e i nostri comportamenti, ma siamo entusiasti di testare i modelli solo una volta che il codice è in produzione. È semplicemente un ripensamento.

Supponiamo che mi venga data una finta pagina con un'intestazione, un corpo e un piè di pagina. Per il bene di questo articolo, il contenuto del corpo non ha importanza, ma come elemento di lavoro, devo fare tutte e tre le cose in uno sprint. Quindi ci sarebbero almeno quattro componenti : a HeaderComponent, BodyComponent, FooterComponent, e a PageComponentche integra le altre tre...

Abbiamo già creato il componente header, ma facciamo finta di non averlo fatto. Se disponiamo di mockup dell'intestazione, potremmo definire cosa dovrebbe essere sempre vero in questo componente:

1. Il componente dovrebbe avvolgere il suo contenuto in un elemento di intestazione.
2. Per impostazione predefinita, se un utente non ha effettuato l'accesso, l'intestazione dovrebbe riportare: "Ciao, utente" in un file h1.
3. Se un utente ha effettuato l'accesso, l'intestazione dovrebbe contenere: "Ciao, {{ Nome utente }}" in un file h1.

Per il test dei componenti, puoi usare Jasmine, Jest o Cypress. Con Jasmine e Jest, fai affidamento su TestBed e utilizzi un dispositivo per afferrare elementi e far valere su di essi. Con Jest, non vedi il modello in un DOM reale, quindi non offre quasi alcun vantaggio reale. Jasmine funziona alla grande qui; pronto all'uso, fa quasi tutto ciò che vuoi che faccia. Vale a dire, essere in grado di percorrere nel tempo i test e guardare le istantanee dei tuoi test. Come ambasciatore di Cypress, probabilmente hai indovinato che preferisco usare Cypress per questo, ea partire da Cypress 10.5 possiamo farlo accadere!

TDD con test dei componenti Cypress

Il test dei componenti Cypress ha una sintassi molto simile al test Cypress End-to-End. Se sai come scrivere un "Cypress Test", sai come scrivere un test sui componenti. Utilizzando i 3 casi di test che ho creato sopra, posso strutturare rapidamente un file di specifiche di test che si riferiscono a ciascuno di essi:

Se hai visto un test Cypress in passato, questo dovrebbe sembrare abbastanza familiare. Se non l'hai fatto, diamo un'occhiata a ogni pezzo:

Dovrebbe essere all'interno di un elemento di intestazione:

it('should contain a header', () => {    
  cy.mount(HeaderComponent);     
  cy.get('header')      
    .should('exist')      
    .should('be.visible');  
});

Il cy.get('header')è l'unico comando seguente. Useremo javascript per ottenere l'elemento header e quindi asseriremo che non solo esiste ma è anche visibile. Questo test fallirà durante l'esecuzione di TDD fino a quando non aggiungeremo un <header></header>elemento al modello.

Per impostazione predefinita, se un utente non ha effettuato l'accesso, l'intestazione dovrebbe riportare: "Hello, User" in un h1.

it('should have an h1 that has a greeting', () => {  
  cy.mount(HeaderComponent);     
  cy.get('h1')      
    .should('have.text', 'Hello, User');  
});

Se un utente ha effettuato l'accesso, l'intestazione dovrebbe contenere: "Ciao, {{ Nome utente }}" in un h1.

it('should display a user name if name is provided', () => {    
  cy.mount(HeaderComponent, {      
    componentProperties: {        
      title: {          
        firstName: 'John',
        lastName: 'Doe'
      }      
    }    
  });       cy.get('h1')      
    .should('have.text', 'Hello, John Doe');
});

Facile, vero?

Riepilogo

Il test dei componenti è interessante! Non è un concetto nuovo, ma è più veloce di quello a cui abbiamo avuto accesso fino all'implementazione di Cypress. Come puoi vedere in alto a destra nel riquadro di sinistra, sono necessari 147 ms per eseguire questi tre test e ogni test richiede meno di pochi minuti per scrivere se il modello del tuo componente è già definito. Con questi test come punto di partenza per questo componente di intestazione, se qualcuno modifica qualcosa che non è d'accordo con le tre specifiche già esistenti, sappiamo che il componente è "rotto" e dobbiamo risolverlo. Poiché si tratta solo di testare l'istanza di HeaderComponent, non possiamo chiamarlo test di integrazione. Non possiamo chiamarlo test unitario, poiché non viene testata alcuna funzionalità. Questo, amici miei, è un test sui componenti!

Questa era già la tua comprensione del test dei componenti in Angular? I tuoi test Jasmine o Jest sono così puliti e veloci? Fammi sapere in che modo il tuo contrasta con questo!

Ci vediamo nel prossimo capitolo, dove esaminerò i test di integrazione.