Automatikus tesztek chai és mokka segítségével

Ebben a fejezetben az automatikus tesztelés alapjait tárgyaljuk. A feladatokat tovább kell alkalmazni, és általánosságban a programozó "oktatási minimum" -ja szerepel.

Funkció írásakor általában azt jelöljük, mit kell tennie, milyen értéket adni az érveknek.

A fejlesztési folyamat során időről időre ellenőrizzük, hogy a funkció megfelelően működik-e. A legegyszerűbb módja annak, hogy futtassa, például a konzolon, és nézze meg az eredményt.

Ha valami baj van, javítsd meg, futtasd újra - lásd az eredményt ... És így "a célig".

De az ilyen kézi indítások nagyon tökéletlen ellenőrzési eszközök.

Ha manuálisan ellenőrizze a kódot - könnyű "megvédeni".

Például írjuk az f funkciót. Mi írtunk, teszteljük különböző érvekkel. Az f (a) függvényhívás működik, de f (b) nem működik. Javította a kódot - f (b) elkezdett dolgozni. valami kész. De ugyanakkor elfelejtették tesztelni az f (a) - upokat, itt egy lehetséges hiba a kódban.

Az automatizált tesztelés akkor történik, ha a teszteket a kódtól elkülönítve írják le, és bármikor lefuttathatják őket, és ellenőrizhetik az összes fontos felhasználást.

Megvizsgáljuk a BDD - Viselkedésvezérelt Fejlesztés részét képező tesztelési módszertant. A BDD megközelítést sok projektben sikeresen alkalmazták.

A BDD nem csak tesztek. Ez sokkal több.

A BDD tesztjei három egyben: és tesztek, és a dokumentáció, valamint a felhasználási példák.

Azonban elég szóval. Vegyünk példákat.

Tegyük fel, hogy a pow (x, n) függvényt szeretnénk fejleszteni. amely x-et emel egész számra. az egyszerűség érdekében, n≥0.

Még a fejlesztés előtt is el tudjuk képzelni, mit fog csinálni ez a funkció, és leírja a BDD technikával.

Ezt a leírást specifikációnak nevezik (vagy, ahogy mondják mindennapi használatban, "speck"), és így néz ki:

A specifikációnak három fő építőeleme van, amelyeket a fenti példában láthat:

Megadja, hogy pontosan mit írunk le, a "munkakörök" csoportosítására használjuk - blokkolja azt. Ebben az esetben a pow függvényt írjuk le.

A címsorában az emberi nyelv leírja, hogy mit kell tenni a feladat, majd a teszt következik. aki ellenőrzi ezt.

A kód benne van. ha a megvalósítás igaz, hibát kell végrehajtani.

A formanyomtatvány különböző funkciói * ellenőrzik, hogy a pow végzi-e a célt. Eddig csak egy érdekelt vagyunk - assert.equal. összehasonlítja az első argumentumát a második értékkel, és hibát ad, ha nem egyenlő. Ebben az esetben ellenőrzi, hogy a pow (2, 3) eredménye 8.

Vannak más összehasonlítások és ellenőrzések is, amelyeket később látni fogunk.

Tipikusan a fejlesztés folyamata a következő:

1. Egy olyan leírás szerepel, amely leírja a legalapvetőbb funkciókat.
2. A kezdeti megvalósítás megtörtént.
3. A specifikációnak való megfelelés ellenőrzéséhez a keretrendszert (a mi esetünkben a Mocha-t) fogjuk használni. A keret mindent tesztel, és hibákat jelez, ha előfordulnak. A hibák kijavítása.
4. A specifikáció kiterjeszti, hozzáadja azokat a szolgáltatásokat, amelyeket a megvalósítás nem támogat.
5. A 2. pontra megyünk, végrehajtunk. És így "a győztes végére".

A fejlesztés iteratív módon történik. Egy passzol a másik után, amíg a specifikáció és a végrehajtás befejeződik.

Esetünkben az első lépés már befejeződött, a kezdeti specifikáció készen áll, jó lenne a végrehajtás megkezdése. De előtte "nullázzuk" a specifikációt, csak azért, hogy lássuk, már ebben a formában, még végrehajtás nélkül is - a tesztek működnek.

A következőket fogjuk használni:

• Mocha - ez a könyvtár közös funkciókat tartalmaz a teszteléshez, beleértve a leírást is.
• Chai - a könyvtár számos funkciót támogat az ellenőrzéshez. Az eredmények ellenőrzéséhez különböző "stílusok" vannak, amelyekkel később megismerkedünk, jelenleg csak assert.equal fogunk használni.
• Sinon - az emulációhoz és a funkciók "csonkjainak" ravasz helyettesítéséhez később lesz szükség.

Ezek a könyvtárak lehetővé teszik a JS tesztelését nem csak a böngészőben, hanem a Node.JS kiszolgálón is. Itt megnézzük a böngészõ verzióját, a szerververzió ugyanazokat a funkciókat használja.

Minta HTML oldal a tesztekhez:

Ez az oldal négy részre osztható:

1. tömb - benne könyvtárakat és stílusokat csatlakoztatunk tesztelésre, kódunk nincs ott.
2. tömb