Front-End-testpyramiden: Sådan genovervejer du din test

Hvis du tester frontend-apps, skal du vide om front-end-testpyramiden .

I denne artikel ser vi på, hvad front-end testpyramiden er, og hvordan man bruger den til at skabe omfattende testpakker.

Front-end testpyramiden

Front-end testpyramiden er en repræsentation af, hvordan en front-end-testpakke skal være struktureret.

Den ideelle testpakke består af enhedstest, nogle øjebliksbillede-tests og et par ende-til-slut-test (e2e).

Dette er en opdateret version af testpyramiden, der er specifik for test af front-end applikationer.

I denne artikel gennemgår vi, hvordan hver af disse testtyper ser ud. For at gøre det opretter vi en testpakke til en eksempelapp.

Appen

For at lære mere om front-end-testpyramiden vil vi se på, hvordan man tester en webapp.

Appen er en simpel modal app. Ved at klikke på en knap åbnes et modal, og ved at klikke på en OK-knap på modalet lukkes modalet.

Vi bygger appen ud fra en komponentbaseret ramme. Du skal ikke bekymre dig om det specifikke - vi holder det på et højt niveau.

Appen er lavet af tre komponenter - en Buttonkomponent, en Modalkomponent og en Appkomponent.

De første tests, vi skriver, er enhedstest. I front-end testpyramiden er størstedelen af ​​vores tests enhedstest.

Enhedstest

Enhed tester testenheder af en codebase.

De kalder direkte på funktioner - eller enheder - og sørger for, at de returnerer det korrekte resultat.

I vores app er vores komponenter enheder. Så vi skriver enhedstest til Button og Modal. Der er ikke behov for at skrive tests til vores Appkomponent, fordi der ikke er nogen logik i den.

Enhedstestene vil lave gengivende komponenter og hævde, at de opfører sig korrekt, når vi interagerer med dem.

Lav gengivelse betyder, at vi gengiver komponenten et niveau dybt. På denne måde kan vi sikre os, at vi kun tester komponenten, vores enhed og ikke en underordnet komponent flere niveauer nede.

I vores tests udløser vi handlinger på komponenterne og kontrollerer, at komponenterne opfører sig som forventet.

Vi ser ikke på koden. Men specifikationerne for vores komponenter ser sådan ud:

  • Modal har klasse er aktiv, når displayModal er sandt
  • Modal har ikke klasse er aktiv, når displayModal er falsk
  • Modal kalder toggleModal, når der klikkes på succes-knappen
  • Modal kalder toggleModal, når der klikkes på knappen slet
  • Knappen kalder toggleModal, når der klikkes på knappen

Vores tests vil gøre overfladiske gengivelser af komponenterne og derefter kontrollere, at hver af specifikationerne fungerer.

Der er et par grunde til, at enhedstest skal udgøre størstedelen af ​​vores testpakke:

Enhedstest er hurtige.

En pakke med hundreder af enhedstest kører på få sekunder.

Dette gør enhedstest nyttige til udvikling. Når refactoring af kode kan vi ændre koden og køre enhedstestene for at kontrollere, at ændringerne ikke brudte komponenten. Vi ved inden for få sekunder, om vi brød noget, fordi en af ​​testene mislykkes.

Enhedstest er granuleret

Med andre ord er de meget specifikke.

Hvis en enhedstest mislykkes, fortæller den ødelagte test os, hvordan og hvorfor den fejler.

Enhedstest er gode til at kontrollere de fine detaljer om, hvordan vores ansøgning fungerer. De er det bedste værktøj, du kan bruge, når du udvikler, især hvis du følger testdrevet udvikling.

Men de kan ikke teste alt.

For at sikre, at vi gengiver den korrekte stil, skal vi bruge snapshot-tests.

Snapshot-tests

Snapshot-tests er tests, der tager et billede af din gengivne komponent og sammenligner det med et tidligere billede af din komponent.

Den bedste måde at skrive snapshot-test på i JavaScript er med Jest.

I stedet for at tage et billede af den gengivne komponent tager Jest et øjebliksbillede af den gengivne komponents markering. Dette gør Jest snapshot-tests meget hurtigere end traditionelle snapshot-tests.

For at registrere en snapshot-test i Jest skal du tilføje noget som koden nedenfor:

const renderedMarkup = renderToString(ModalComponent)expect(renderedMarkup).toMatchSnapshot()

Når du registrerer et øjebliksbillede, tager Jest sig af alt andet. Hver gang enhedstestene køres, regenereres det et øjebliksbillede og sammenligner det med det forrige øjebliksbillede.

Hvis koden ændres, kaster Jest en fejl og advarer om, at markeringen er ændret. Udvikleren kan derefter kontrollere manuelt, at ingen klasse er blevet slettet ved et uheld.

I testen nedenfor har nogen slettet modal-card-footklassen fra er>.

Snapshot tests are a way of checking nothing has changed about the style or markup of a component.

If the snapshot tests pass, we know our code change didn’t affect the display of our components.

If the tests fail, then we know that we did affect the render of the components and can check manually that the style is still correct.

You should have at least 1 snapshot test per component. A typical snapshot test renders the component with some state to check it renders correctly.

Now we have unit tests and snapshot tests, it’s time to look at end to end (e2e) tests.

End to end tests

End to end (e2e) tests are high-level tests.

They perform the same actions as we would if we tested an App manually.

In our app we have a user journey. When the user clicks on the button the modal will open, when they click the button in the modal the modal closes.

We can write an end to end test that runs through this journey. The test will open the browser, navigate to the webpage, and run through each action to make sure the app is behaving correctly.

These tests tell us that our units are working together correctly. It gives us high confidence that the main functionality of the app is working.

There are a few ways to write end to end tests for JavaScript applications. There are programs like test cafe that record you performing actions in a browser and replay them as tests.

There are also projects like nightwatch that let you write the tests in JavaScript. I would recommend using a library like nightwatch. It’s easy to pick up, and the tests run faster than recorded tests.

That said, nightwatch tests are still relatively slow. A suite of 200 unit tests takes seconds to run, a suite of 200 end to end tests takes minutes to run.

The other problem with end to end tests is that they are difficult to debug. When a test fails, it’s hard to find out why it failed, because the tests cover a lot of functionality.

Conclusion

To test front-end component based web apps effectively, you need to three types of tests. Unit tests, snapshot tests, and e2e tests.

You should have multiple unit tests for each component, one or two snapshot tests per component, and one or two end to end tests that test multiple components connected together.

Overall unit test will make up the bulk of your tests, you’ll have some snapshot tests, and a few e2e tests.

If you follow the front-end testing pyramid, you’ll create maintainable web apps with killer test suites.

You can see an example repository of the app with snapshot tests, unit tests, and end to end tests on GitHub.