Ez a cikk feltételezi, hogy az olvasó ismeri az ECMAScript 2015 (ES6) szintaxisát és a MochaJS-t, és jelenleg az aszinkron tesztjeit ECMAScript 2016 (ES7) formátumra próbálja átalakítani.

Tegyük fel, hogy már van egy getFruits nevű TDD-metódusunk, amely meghívja a fetch ​​ parancsot, amelyre gyümölcsgyűjtemény (tömb) formájában válaszol.

Az ehhez tartozó egységteszt így néz ki.

Mielőtt elkezdené az egységtesztünk átalakítását, vessünk egy rövid részletet, amely elmagyarázza, miért tesztelik így a gyümölcstárat. Azt is észreveheti, hogy a BDD "Adott-mikor-akkor" fogalmát használom a tesztleírások írásakor. Ez segít megszervezni a tesztünket, és sokkal könnyebbé teszi a „grok”-ot.

Az egységteszt fájlunkban négy modult importálunk.

A fetch-et a sinon-szal akarjuk csonkolni, mert ez egy külső aszinkron hívás. Ezt úgy tehetjük meg, hogy a fetch metódust a global objektumba helyezzük.

Nem fogjuk csonkolni a gyümölcstárat, mert ez a "Tesztelés alatti rendszer (SUT)".

Soha ne tönkretegye a tesztelt rendszert. Valaha.

Soha nem csonkítja el a tesztelt rendszert, mert a csonkítással módosítja a tesztelni kívánt rendszer viselkedését. A SUT viselkedésének módosításával többé nem tudja tesztelni a tényleges viselkedését, ami az elsődleges oka annak, hogy amúgy is egységtesztet ír.

Minden teszt megkezdése előtt homokozóba helyezzük a sinon csonkokat, így a tesztben felhasznált összes csonkot elkülönítjük. Ezután minden teszt után visszaállítjuk az eredeti működését.

Első tesztünk arról szól, hogy ellenőrizzük, valóban hívjuk-e a fetch szolgáltatást minden alkalommal, amikor a getFruits szolgáltatást hívjuk.

Tekintettel a gyümölcstárra. Gyümölcsgyűjtemény beszerzésekor. Meg kell hívnia a fetch-et.

Most, hogy meggyőződtünk arról, hogy valóban hívjuk a fetch parancsot minden alkalommal, amikor gyümölcsgyűjteményt próbálunk szerezni, itt az ideje, hogy megtudjuk, megkapjuk-e az adatokat, amikor a hívás sikeres. em>

Mivel letiltottuk a fetch funkciót, le kell csillapítanunk néhány olyan metódust, amelyekre szükségünk van benne, például a json-t. Definíció szerint olyan ígéretet ad vissza, amely a JSON-adatokat tartalmazó objektumliterállal oldódik meg.

Gondoskodnunk kell arról is, hogy ígéretünk feloldása soha ne futtassa a catch záradékunkat. Ezért hozzáadunk egy sikertelen tesztet, ahol ellenőrizzük, hogy a hamis egyenlő-e az igaz értékkel.

Tekintettel a gyümölcstárra. Amikor egy gyűjtemény gyümölcsöt és sikeres. Egy sor gyümölcsöt kell visszaadnia.

Most, hogy tudjuk, hogy a megfelelő adatokat kapjuk. Ki kell derítenünk, hogy a megfelelő hibaüzenetet kapjuk-e, ha a gyümölcsgyűjtés sikertelen.

Csakúgy, mint a sikeres tesztünknél, meg kell győződnünk arról, hogy az ígéret elutasítása nem futja az akkor záradékot.

Tekintettel a gyümölcstárra. Amikor egy gyűjtemény gyümölcsöt, és sikertelen. Hibaobjektumot kell visszaadnia.

tl;dr

  • Tesztelje, hogy a fetch meghívása pontosan a megfelelő argumentumokkal történik-e
  • Tesztelje a boldog utat – ha a szolgáltatás sikeres
  • Tesztelje a szomorú utat – ha a szolgáltatás sikertelen

Itt az ideje, hogy újra faktoráljuk a forrásfájlt és a megfelelő egységtesztet.

Már megvan az Promise, miért van szükségünk az async/awaitre?

Az aszinkron/várakozás segítségével úgy érezheti, mintha szinkron kódot írna, miközben továbbra is aszinkron kódot ír. Egyszerű lekérdezések esetén az Ígéret könnyen érthető. Amint azonban a követelmények egyre bonyolultabbakká válnak, a szinkron érzés nagymértékben csökkenti a bonyolultságot.

Most, hogy az async/await funkciót használjuk, visszatérhetünk a try/catch/finally használatához, ami szinkron kódnak tűnik.

Csakúgy, mint a forrásfájl, az egységtesztünket is újra faktoráljuk.

Mivel most már használhatja avégre yet, észre fogja venni, hogy az első tesztünk már sokkal könnyebben érthető. A végül záradék a try és a catch záradék végrehajtása után hajtódik végre. Pontosan erre van szüksége, mert függetlenül attól, hogy az ígéret bevált-e vagy sem, tudnia kell, hogy a fetch meghívása egyszer és pontosan a megfelelő érvekkel történik-e.

Ugyanez vonatkozik a sikeres tesztre is, ahelyett, hogy végre gondoskodnánk arról, hogy a catch záradék soha ne futjon le. És ha ez megtörténik, egy sikertelen tesztnek kell figyelmeztetnie minket.

Ami a sikertelen tesztünket illeti, a try záradék mindig végrehajtásra kerül, így nincs szükség várt sikertelen tesztre.

És ott van. Újrafaktorálta az aszinkron kódot az async/await használatára.