Überblick

Im vorherigen Artikel habe ich „Unit Testing“ definiert und wie wir diese Tests auf unsere Angular-Anwendung anwenden können. Wir sind uns einig, dass unsere Geschäftslogik per Definition außerhalb unserer Komponenten liegen sollte und der Großteil unserer Funktionalität in Pipes, Direktiven und Diensten liegen wird, was bedeutet, dass die meisten unserer Unit-Tests diese Arten von Klassen testen werden. In diesem Artikel habe ich auch einen Überblick über eine Angular-Komponente gepostet, deren Templating-Logik von der Komponente in eine Pipe verschoben wurde, sodass nur ein Input()in der Klassendefinition und etwas Templating zurückbleibt. Wir sind uns alle einig, dass jederzeit jemand hineingehen und Elemente im Element hinzufügen oder entfernen könnte, und es gibt keine Menge von Komponententests, die diese Änderungen erfassen könnten.

Wenn Sie Komponententests also nicht verwenden können, um eine Komponente richtig zu testen, bleiben Ihnen nur entweder Komponenten-, Integrations- oder End-to-End-Tests.

Integrationstests könnten funktionieren, aber per Definition treten Integrationstests auf, wenn Sie einzelne Einheiten testen und sie kombinieren, um sie als Gruppe zu testen. Sie könnten also zum Beispiel mit testen ComponentA, ComponentBund das ist in einigen Fällen wahrscheinlich in Ordnung. Aber was passiert, wenn Sie ComponentAmit integrieren ComponentC? Können Sie sagen, dass der erste Test, den Sie erstellt haben, gut genug ist, um Ihr Produkt in die Produktion zu schicken?

Laut den Angular-Dokumenten :

Die Grundbausteine ​​des Angular-Frameworks sind Angular-Komponenten…

Komponenten sind so konzipiert, dass sie mit verschiedenen Komponenten kombiniert und von diesen genutzt werden können, um Ihre Anwendung zu erstellen. Daher müssen Sie sicherstellen können, dass Sie eine Quelle der Wahrheit für das DOM haben, insbesondere Ihre Barrierefreiheitsfunktionen Inputund Output-eigenschaften sowie alle Stile, die Sie für relevant halten, um sicherzustellen, dass sie immer gültig sind und dass Sie sie nicht testen müssen manuell.

Kehren wir zur Header-Komponente zurück:

Auf den ersten Blick gibt es nicht viel zu testen . In einer idealen Welt wüssten wir, dass die NameDisplayPipeüber Tests verfügt, die die von der Komponente bereitgestellten Werte validieren und das zurückgeben, was wir erwarten. Aber was passiert, wenn jemand aus Versehen das h1an ein anpasst h2? Was passiert, wenn jemand versehentlich die Initialisierung des Titels entfernt?

Komponententests zur Rettung

Das Testen von Komponenten ist unglaublich, da es die Notwendigkeit beseitigt, viele Dinge manuell zu testen, an die wir uns gewöhnt haben, manuell zu testen. Ich kenne zum Beispiel nur wenige Entwickler, die daran denken, die Struktur des Templates der Komponente (der wichtigste Teil) durch Tests zu definieren; Ich kenne jedoch viele QAs und Designer, die diese Dinge manuell überprüfen. Es ist jedoch etwas, worüber wir im Allgemeinen nicht sprechen. Wir sind fest davon überzeugt, dass wir unsere Funktionalität und unser Verhalten testen, aber wir testen Vorlagen erst, wenn der Code in Produktion ist. Es ist einfach ein nachträglicher Einfall.

Angenommen, ich bekomme ein Scheinbild einer Seite mit einer Kopfzeile, einem Hauptteil und einer Fußzeile. Für diesen Artikel spielt der Inhalt des Körpers keine Rolle, aber als ein Arbeitselement soll ich alle drei Dinge in einem Sprint erledigen. Es gäbe also mindestens vier Komponenten : a HeaderComponent, BodyComponent, FooterComponent, und a PageComponent, das die anderen drei integriert …

Wir haben die Header-Komponente bereits erstellt, aber tun wir so, als hätten wir es nicht getan. Wenn wir Mockups des Headers haben, könnten wir definieren, was in dieser Komponente immer wahr sein muss:

1. Die Komponente sollte ihren Inhalt in ein Header-Element einschließen.
2. Wenn ein Benutzer nicht angemeldet ist, sollte die Kopfzeile standardmäßig „Hello, User“ in einer h1.
3. Wenn ein Benutzer angemeldet ist, sollte die Kopfzeile lauten: „Hallo, {{ Benutzername }}“ in einer h1.

Zum Testen von Komponenten können Sie Jasmine, Jest oder Cypress verwenden. Bei Jasmine und Jest sind Sie auf TestBed angewiesen und verwenden eine Vorrichtung, um Elemente zu greifen und auf ihnen zu behaupten. Bei Jest sehen Sie die Vorlage nicht in einem tatsächlichen DOM, sodass es fast keinen wirklichen Nutzen bringt. Jasmine funktioniert hier großartig; Out-of-the-Box macht es fast alles, was Sie wollen. Nämlich in der Lage zu sein, die Tests zeitlich zu durchlaufen und sich Schnappschüsse Ihrer Tests anzusehen. Als Cypress-Botschafter haben Sie wahrscheinlich schon erraten, dass ich dafür lieber Cypress verwende, und ab Cypress 10.5 können wir das möglich machen!

TDD mit Cypress-Komponententests

Das Cypress-Komponententesten hat eine sehr ähnliche Syntax wie das Cypress-End-to-End-Testen. Wenn Sie wissen, wie man einen „Cypress-Test“ schreibt, wissen Sie, wie man einen Komponententest schreibt. Mit den 3 oben erstellten Testfällen kann ich schnell eine Spezifikationsdatei mit Tests strukturieren, die sich auf jeden von ihnen beziehen:

Wenn Sie in der Vergangenheit einen Cypress-Test gesehen haben, sollte Ihnen dieser ziemlich bekannt vorkommen. Wenn nicht, werfen wir einen Blick auf jedes Stück:

Es sollte sich in einem Header-Element befinden:

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

Das cy.get('header')ist der einzige folgende Befehl. Wir verwenden Javascript, um das Header-Element abzurufen, und bestätigen dann, dass es nicht nur existiert, sondern auch sichtbar ist. Dieser Test schlägt bei TDD fehl, bis wir <header></header>der Vorlage ein Element hinzufügen.

Wenn ein Benutzer nicht angemeldet ist, sollte die Kopfzeile standardmäßig lauten: „Hallo, Benutzer“ in einem h1.

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

Wenn ein Benutzer angemeldet ist, sollte der Header lauten: „Hallo, {{ Benutzername }}“ in einem 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');
});

Einfach richtig?

Zusammenfassung

Komponententests sind interessant! Es ist kein neues Konzept, aber es ist schneller als das, worauf wir bis zur Implementierung von Cypress Zugriff hatten. Wie Sie oben rechts in diesem linken Bereich sehen können, dauert es 147 ms, um diese drei Tests auszuführen, und das Schreiben jedes Tests dauert weniger als ein paar Minuten, wenn die Vorlage Ihrer Komponente bereits definiert ist. Mit diesen Tests als Ausgangspunkt für diese Header-Komponente wissen wir, dass die Komponente „kaputt“ ist, wenn jemand etwas ändert, das nicht mit den drei bereits vorhandenen Spezifikationen übereinstimmt, und wir uns darum kümmern müssen. Da dies nur die Instanz der HeaderComponent testet, können wir es nicht als Integrationstest bezeichnen. Wir können dies nicht als Komponententest bezeichnen, da keine Funktionalität getestet wird. Das, meine Freunde, ist ein Komponententest!

War das bereits Ihr Verständnis von Component Testing in Angular? Sind Ihre Jasmin- oder Jest-Tests so sauber und schnell? Lassen Sie mich wissen, wie sich Ihre davon abheben!

Wir sehen uns im nächsten Kapitel, in dem ich auf Integrationstests eingehen werde.