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.