Przegląd

W poprzednim artykule zdefiniowałem „testy jednostkowe” oraz to, w jaki sposób możemy zastosować te testy w naszej aplikacji Angular. Zgadzamy się, że z definicji nasza logika biznesowa powinna działać poza naszymi komponentami, a większość naszej funkcjonalności będzie znajdować się w potokach, dyrektywach i usługach, co oznacza, że ​​większość naszych testów jednostkowych będzie testować tego typu klasy. W tym artykule zamieściłem również sedno komponentu Angular z logiką szablonów przeniesioną z komponentu do potoku, pozostawiając jedynie Input()definicję klasy i trochę szablonów. Wszyscy zgodzilibyśmy się, że w dowolnym momencie ktoś może wejść i dodać lub usunąć elementy w elemencie, a nie ma liczby testów jednostkowych, które mogłyby uchwycić te zmiany.

Tak więc, jeśli nie możesz użyć testów jednostkowych do prawidłowego przetestowania komponentu, pozostaje ci tylko testowanie komponentowe, integracyjne lub kompleksowe.

Testy integracyjne mogą działać, ale z definicji testowanie integracyjne ma miejsce, gdy testujesz poszczególne jednostki i łączysz je w celu przetestowania jako grupa. Na przykład możesz przetestować ComponentAza pomocą ComponentB, co prawdopodobnie jest w porządku w niektórych przypadkach. Ale co się stanie, gdy zintegrujesz ComponentAsię z ComponentC? Czy czujesz się komfortowo, mówiąc, że pierwszy utworzony test jest wystarczająco dobry, aby wysłać produkt do produkcji?

Według dokumentów Angulara :

Podstawowymi elementami budulcowymi frameworka Angular są komponenty Angular…

Komponenty są zaprojektowane do łączenia i używania przez różne komponenty w celu zbudowania aplikacji. Dlatego musisz być w stanie upewnić się, że masz jakieś źródło prawdy dla DOM, w szczególności twoje funkcje Inputi Outputwłaściwości ułatwień dostępu oraz wszelkie style, które uważasz za istotne, aby upewnić się, że są one zawsze ważne i że nie będziesz musiał testować ręcznie.

Wróćmy do komponentu Header:

Na pierwszy rzut oka nie ma co testować . W idealnym świecie wiedzielibyśmy, że NameDisplayPipema testy, które weryfikują wartości dostarczane przez komponent i zwracają to, czego oczekujemy. Ale co się stanie, jeśli ktoś przypadkowo dostosuje h1do h2? Co jeśli ktoś przypadkowo usunie inicjalizację tytułu?

Testowanie komponentów na ratunek

Testowanie komponentów jest niesamowite, ponieważ eliminuje potrzebę ręcznego testowania wielu rzeczy, do których jesteśmy przyzwyczajeni. Na przykład znam tylko kilku programistów, którzy myślą o zdefiniowaniu struktury szablonu komponentu (najważniejszej części) za pomocą testów; znam jednak wielu kontrolerów jakości i projektantów, którzy ręcznie sprawdzają te rzeczy. Jednak jest to coś, o czym na ogół nie rozmawiamy. Jesteśmy nieugięci w testowaniu naszej funkcjonalności i zachowań, ale jesteśmy zainteresowani testowaniem szablonów dopiero po uruchomieniu kodu. To po prostu refleksja.

Załóżmy, że dostaję próbkę strony z nagłówkiem, treścią i stopką. Na potrzeby tego artykułu zawartość ciała nie ma znaczenia, ale jako jeden element pracy mam wykonać wszystkie trzy rzeczy w jednym sprincie. Byłyby więc co najmniej cztery komponenty : a HeaderComponent, BodyComponent, FooterComponent, i a PageComponent, które integrują pozostałe trzy…

Utworzyliśmy już komponent nagłówka, ale udawajmy, że tego nie zrobiliśmy. Jeśli mamy makiety nagłówka, możemy zdefiniować, co zawsze musi być prawdziwe w tym komponencie:

1. Komponent powinien zawijać swoją zawartość w elemencie nagłówka.
2. Domyślnie, jeśli użytkownik nie jest zalogowany, nagłówek powinien brzmieć: „Hello, User” w pliku h1.
3. Jeśli użytkownik jest zalogowany, nagłówek powinien brzmieć: „Hello, {{ User Name }}” w pliku h1.

Do testowania komponentów można użyć Jasmine, Jest lub Cypress. Z Jasmine i Jest polegasz na TestBed i używasz uchwytu do chwytania elementów i potwierdzania ich. W Jest nie widzisz szablonu w prawdziwym DOM, więc prawie nie daje to żadnych realnych korzyści. Świetnie sprawdza się tutaj jaśmin; po wyjęciu z pudełka robi prawie wszystko, co chcesz. Mianowicie możliwość przeglądania testów w czasie i przeglądania migawek testów. Jako ambasador Cypress, prawdopodobnie zgadłeś, że wolę używać do tego Cypress, a od Cypress 10.5 możemy to zrobić!

TDD z testowaniem komponentów Cypress

Testowanie komponentów Cypress ma bardzo podobną składnię jak testy Cypress End-to-End. Jeśli wiesz, jak napisać „Test cyprysowy”, wiesz, jak napisać test komponentów. Korzystając z 3 przypadków testowych, które utworzyłem powyżej, mogę szybko utworzyć plik specyfikacji testów, które odnoszą się do każdego z nich:

Jeśli w przeszłości widziałeś test Cypressa, powinien on wyglądać znajomo. Jeśli nie, rzućmy okiem na każdy element:

Powinien znajdować się w elemencie nagłówka:

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

Jest cy.get('header')to jedyne następujące polecenie. Użyjemy javascript, aby pobrać element nagłówka, a następnie stwierdzimy, że nie tylko istnieje, ale jest również widoczny. Ten test zakończy się niepowodzeniem podczas wykonywania TDD, dopóki nie dodamy <header></header>elementu do szablonu.

Domyślnie, jeśli użytkownik nie jest zalogowany, nagłówek powinien brzmieć: „Hello, User” w h1.

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

Jeśli użytkownik jest zalogowany, nagłówek powinien brzmieć: „Hello, {{ User Name }}” w 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');
});

Łatwe, prawda?

Streszczenie

Testowanie komponentów jest interesujące! Nie jest to jakaś nowa koncepcja, ale jest szybsza niż ta, do której mieliśmy dostęp przed wdrożeniem Cypressa. Jak widać w prawym górnym rogu tego lewego panelu, uruchomienie tych trzech testów zajmuje 147 ms, a napisanie każdego testu zajmuje mniej niż kilka minut, jeśli szablon twojego komponentu jest już zdefiniowany. Biorąc pod uwagę te testy jako punkt wyjścia dla tego komponentu nagłówka, jeśli ktoś zmieni coś, co nie jest zgodne z trzema istniejącymi specyfikacjami, wiemy, że komponent jest „zepsuty” i musimy się tym zająć. Ponieważ jest to tylko testowanie instancji komponentu HeaderComponent, nie możemy tego nazwać testem integracyjnym. Nie możemy tego nazwać testem jednostkowym, ponieważ nie jest testowana żadna funkcjonalność. To, moi przyjaciele, jest test komponentów!

Czy tak już rozumiesz testowanie komponentów w Angular? Czy Twoje testy Jasmine lub Jest są tak czyste i szybkie? Dajcie znać, jak Wasze kontrastują z tym!

Do zobaczenia w następnym rozdziale, w którym omówię testy integracyjne.