Az alábbiakban néhány JavaScript nyelvre alkalmazható Unit Test rövid leírása található.
A kliens oldali egységek (Unit) tesztelésének egy igen nagy nehézsége az egységek hiánya. Ez többek között azért is fordulhat elő, mivel a JS kódok egy-egy weboldalon vagy egy alkalmazás különböző moduljaira külön-külön íródott háttér-, felületi logika és HTML oldalak egyvelegét alkotva. Továbbá a HMTL oldalakon gyakran használt események is megnehezítik a dolgunkat. Illetve a DOM használata is bonyolítja a tesztelést, mivel az egyes függvények a különböző DOM értékek alapján különböző eredményeket adhatnak.
Az alábbiakban a QUnit eszközön keresztül adunk egy kis bevezetést a JS Unit Test-elésbe. Először vegyünk egy egyszerű példafüggvényt:
Teszteléshez elég letöltenünk a QUnit oldaláról magát az eszközt tartalmazó .js fájlt, illetve a szebb megjelenítés érdekében a .css fájlt. Ezeket belinkelve a kódba már alkalmazhatjuk is:
Ebben a példában egy egyszerű </div> tag-be rakjuk teszt eredményét. A tesztek futtatására a test használható, aminek paraméterében megadhatjuk a teszt nevét, illetve a lefuttatandó teszteket. Jelen esetben egy függvény törzsében hívjuk meg több esetben a cf függvényt, egy a*sqrt(b) műveletet hajt végre, (a,b) paraméterek esetén. A függvény eredményét az equal metódussal tudjuk ellenőrizni. Előredefiniált paraméterátadás esetén a várt értékkel egyeztetjük. Ha a eredménye nem egyezik meg a várt eredménnyel, akkor a teszt jelenezni fog.
Ha megnyitjuk a html oldalt egy böngészőben (ügyelve hogy a fájlstruktúrában a html oldallal egy mappában helyezkednek el a QUnit .js, ill. .css fájljai, vagy esetleg átírva az elérési utat), látható egy kellemes környezetben a tesztek eredménye. Mégpedig a 4 tesztből 3 sikeres, 1 sikertelen, ugyanis az utolsó esetben a gyök alatt negatív érték szerepel, ami JavaScript-ben NaN értéket eredményez. Ugyanakkor a szorzás eredménye a komplex számsíkon 0 lenne, így a várt értéknek 0-t adunk meg. Ez eset könnyen lekezelhető egy feltétel ellenőrzésével:
És így már minden tesztünk sikeresen lefut. Nyilvánvalóan ez a példa nem túl gyakorlatias és nagyon leegyszerűsített, de jól tükrözi, hogy egyes bizonyos esetek lekezelésének hiányát könnyedén ki lehet szűrni egy-egy ilyen teszttel.
Ezek után vegyünk egy DOM objektumokkal foglalkozó kódot. Ezúttal a függvényünk legyen az alábbi:
Ez nem csinál mást, mint a paraméterben átadott string szavait, elválasztó jelként a szóközt tekintve, egy tömbbe szúrja be, majd visszaadja annak utolsó elemét, azaz az utolsó szót. A mi esetünkben bemenetként egy angol írásmódú nevet várunk, és visszaadjuk a családnevet. Továbbá tekintsük az alábbi metódust, ami végigiterál a paraméterben átadott azonosítóval rendelkező </div> tag paragrafusain (</p> elemek), majd a tartalmukat frissíti az eredeti tartalmon lefuttatott getLastName() függvény eredményével. Legyen a tesztoldalunk az alábbi:
Az első teszt ellenőrzi néhány névre a getLastName() működését. A második teszt ellenőrzi az paragrafusok tartalmát, majd az updateName() meghívása után ismét ellenőrzi azokat, amiknek már csak az utolsó nevét kell tartalmazniuk. Láthatóan mindkét teszt sikeres.
Korábban már használtuk az equal függvényt. A QUnit összesen 3 féle visszajelzést biztosít a teszteléshez:
Használatukra egy példa:
A QUnit biztosít speciális visszajelzést, amivel meg tudjuk határozni, hogy mennyi visszajelzést várunk a teszt végrehajtása alatt. Ha nem a várt számú visszajelzés történik, a teszt elbukik, függetlenül a többi visszajelzés eredményétől. Ezek számát az expect() függvénnyel tudjuk meghatározni. Így a Callback függvények ellenőrzésére is kapunk egy kézenfekvő megoldást:
Itt az expect() függvénnyel beállítjuk 2-ra a várt visszajelzések számát, definiáljuk a calc() Callback függvényt, ami elvégzi az átadott operandusokra az átadott operátort, majd visszaadja ennek eredményét. A result változóban eltároljuk a calc() függvény eredményét, olyan operandussal meghívva, ami tartalmaz egy visszajelzést. Ezzel biztosítjuk, hogy csak a calc lefutása esetén legyen sikeres a teszt. Végül ellenőrizzük a számítás eredményét.
Aszinkron Callback függvények tesztelésére az asyncTest() függvényt lehet használni:
A start függvény meghívásával jelezhetjük, hogy a teszt blokkja befejeződött, kész a visszatéréshez. Ebben az esetben 1 visszajelzést várunk, így az expect metódus az 1 paraméterrel hívjuk meg. A setTimeout arra szolgál, hogy egy meghatározott idő múlva meghívja az átadott függvényt aszinkron, s közben a vezérlés tovább haladjon. Azonban a testAsync csak akkor kezdi el ellnőrizni a visszajelzésetket miután meghívtuk a start metódust. Így a helyett, hogy a teszt a blokk végére érve hibásnak ítélné végrehajtást, a visszajelzést hiányában, megvárja a start meghívását, és csak utána ellenőrzi.
A felhasználói akciókon alapuló kód általában nem tesztelhető megfelelően csupán függvények meghívásával és azok eredményeinek vizsgálatával. Az ilyen események teszteléséhez használhat a jQuery trigger() függvénye. Ha nem akarjuk a kiváltani az eseményt, akkor a triggerHandler() függvény meghívásával tudjuk szimulálni a hozzá kötött akciót. Például ha egy linken akarjuk vizsgálni a click() eseményt igen hasznos lehet, ugyanis ilyenkor általában az esemény kiváltódása után megváltozik a cím. Vegyük a QUnit példáját:
Itt definiálunk egy KeyLogger() függvényt, ami a paraméterben átadott objektumot beállítja target mezőjébe, leköti a keydown() eseményről Callback függvényét, majd hozzáköt egy függvényt, ami hozzáadja a KeyLogger() log mezőjéhez a keydown() esemény billentyűkódját. Legyen a teszt szintén a QUnit példája kódja:
Ez a KeyLogger()-errel létrehozott keys objektum target attribútumába beállítja a document objektumot. Szimuláció képpen kontruál egy keydown eseményt, aminek a billentyűkódját 9-re állítja, majd ellen document objektumra kiváltja azt és ellenőrzi a keys log-ját, hogy tartalmazza-e a megfelelő billentyűkódot. Ne felejtsük el letölteni a jQuery kódját és megfelelően beimportálni!
Ha a tesztelendő eseménykezelő nem az esemény valamely speciális paraméterén alapul, akkor természetesen elég csak az eseményt kiváltani. Ha azonban használ valami ilyen paramétert, akkor a $.Event eseménnyel létre is kell az objektumát.
Fontos, hogy minden a teszt szempontjából releváns eseményt kiváltsunk. Például egy dragging() esemény egy egérlenyomás, legalább egy egérmozgatás és egy egérfelengedés eseményből épül fel. Hasonlóan, az egyszerűnek tűnő click() esemény valójában egy egérlenyomás és egy egérfelengedés is egyben.
Ugyan a QUnit-al igen sok esetet lehet ellenőrizni, például a node.js féle kliens/szerver koncepció tesztelését. Az alábbiakban néhány egyéb, jóval több lehetőséget kínáló eszközt sorolunk fel a közvélemény megjegyzéseivel.
John Resig, a jQuery megalkotója által fejlesztett eszköz a JavaScript elosztott teszteléséhez. Leginkább nyílt forráskódú JS projektek teszteléséhez készült.
A Google által fejlesztett () eloszotott JS eszköz. Hasonlaón a TestSwarm-hoz van kliens/szerver kapcsolat, de támogatja a parancssorból való tesztelést is.
A JsTestDriver-hez hasonló szerver/kliens koncepciójú eszköz, kivéve hogy a szervert JS-ben (node.js) írták Java helyett. Ennek megfelelően automatikusan lefuttatja a teszteket. QUnit-hoz hasonló statikus HTML oldalakban írhatóak a tesztek, ún, fej néküli böngészőkben tesztel (phantomjs, jsdom, …).