Az elülső teszt piramisa: Hogyan gondolja át a tesztelését

Ha elülső alkalmazásokat tesztel, akkor tudnia kell a kezelőfelület tesztpiramisáról .

Ebben a cikkben megnézzük, mi is az a front-end tesztpiramis, és hogyan használhatjuk átfogó tesztcsomagok létrehozására.

A front-end tesztpiramis

A front-end tesztpiramis annak bemutatása, hogyan kell felépíteni a front end tesztcsomagot.

Az ideális tesztcsomag egységtesztekből, néhány pillanatkép-tesztből és néhány végponttól végig (e2e) tesztből áll.

Ez a tesztpiramis megújult változata, amely kifejezetten a front-end alkalmazások tesztelésére szolgál.

Ebben a cikkben áttekintjük, hogy néznek ki ezek a teszttípusok. Ehhez létrehozunk egy tesztcsomagot egy példa alkalmazáshoz.

Az alkalmazás

Az elülső tesztpiramis részletes ismertetéséhez megnézzük, hogyan tesztelhetünk egy webalkalmazást.

Az alkalmazás egy egyszerű modális alkalmazás. Egy gombra kattintva megnyílik a modál, és az OK gombra kattintva a modál bezárul.

Az alkalmazást egy összetevő alapú keretrendszerből építjük fel. Ne aggódjon a sajátosságok miatt - ezt a magas szinten tartjuk.

Az alkalmazás három komponensből áll - egy Buttonkomponensből, egy Modalkomponensből és egy Appkomponensből.

Az első tesztek, amelyeket írunk, az egységtesztek. A front-end tesztpiramisban tesztjeink nagy része egység teszt.

Egységvizsgálatok

Az egység egy kódalap tesztegységeit teszteli.

Közvetlenül hívják a függvényeket - vagy egységeket -, és ügyelnek arra, hogy a helyes eredményt adjanak vissza.

Az alkalmazásunkban összetevőink egységek. Tehát írunk egység teszteket a Button és a Modal számára. Nincs szükség tesztek írására a Appkomponensünk számára, mert nincs benne logika.

Az egységtesztek sekély renderelést eredményeznek és azt állítják, hogy helyesen viselkednek, amikor kölcsönhatásba lépünk velük.

A sekély megjelenítés azt jelenti, hogy az alkatrészt egy szint mélyre nyújtjuk. Így megbizonyosodhatunk arról, hogy csak az alkotóelemet, az egységünket teszteljük, és nem egy gyermekkomponentot, több szinttel lejjebb.

Tesztjeink során műveleteket indítunk az alkatrészeken, és ellenőrizzük, hogy az alkatrészek a várt módon viselkednek-e.

Nem nézzük meg a kódot. De alkatrészeink specifikációi így néznek ki:

  • A Modal osztálya aktív, ha a displayModal igaz
  • Ha a displayModal hamis, akkor a Modalnak nincs osztálya-aktív
  • A modális hívások toggleModal, amikor a siker gombra kattintanak
  • A modális hívások toggleModal, amikor a törlés gombra kattintanak
  • A gomb meghívása toggleModal, amikor a gombra kattint

Tesztjeink sekélyen előállítják az alkatrészeket, majd ellenőrzik az egyes előírások működését.

Néhány oka annak, hogy az egységvizsgálatoknak kell a tesztcsomagunk nagy részét kitenniük:

Az egységvizsgálatok gyorsak.

Több száz egység tesztből álló csomag néhány másodperc alatt lefut.

Ezáltal az egységtesztek hasznosak a fejlesztés során. A kód visszafejlesztésekor megváltoztathatjuk a kódot, és futtathatjuk az egységteszteket annak ellenőrzésére, hogy a változtatások nem törtek-e meg az alkatrészen. Pár másodpercen belül megtudjuk, hogy elrontottunk-e valamit, mert az egyik teszt kudarcot vall.

Az egységvizsgálatok szemcsések

Más szavakkal, nagyon specifikusak.

Ha az egység teszt sikertelen, akkor a törött teszt megmondja, hogyan és miért nem sikerül.

Az egységtesztek alkalmasak az alkalmazásunk működésének finom részleteinek ellenőrzésére. Ők a legjobb eszköz a fejlesztés során, különösen, ha teszt alapú fejlesztést követ.

De nem tudnak mindent tesztelni.

A megfelelő stílus megjelenítéséhez pillanatkép-teszteket kell használnunk.

Pillanatkép tesztek

A pillanatfelvételi tesztek olyan tesztek, amelyek lefényképezik a renderelt összetevőt, és összehasonlítják azt a komponens előző képével.

A pillanatkép-tesztek JavaScript-beírásának legjobb módja a Jest.

Ahelyett, hogy lefényképezné a renderelt alkatrészt, Jest pillanatfelvételt készít a renderelt komponens jelöléséről. Ez sokkal gyorsabbá teszi a Jest pillanatfelvételi tesztjeit, mint a hagyományos pillanatfelvételi tesztek.

Pillanatkép teszt regisztrálásához a Jest-ben hozzá kell adnia valamit, például az alábbi kódot:

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

Miután regisztrált egy pillanatfelvételt, Jest minden mással foglalkozik. Minden alkalommal, amikor az egység tesztjei lefutnak, egy pillanatfelvételt készít, és összehasonlítja az előző pillanatképpel.

Ha a kód megváltozik, a Jest hibát dob, és figyelmeztet arra, hogy a jelölés megváltozott. A fejlesztő ezután manuálisan ellenőrizheti, hogy egyetlen osztályt sem töröltek-e véletlenül.

Az alábbi teszten valaki törölte az modal-card-footosztályt a 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.