Intro
Jeg har været at udforske test af enheder og teste dækning for JavaScript, som jeg arbejder på en ny SharePoint app for SharePoint online i Office 365 Suite. De åbenlyse forskning stier førte mig til Qunit.js og lige efter at, til Blanket.js.
QUnit Lad mig oprette unit-tests og gruppere dem i moduler. Et modul er bare en simpel måde at organisere relaterede tests. (Jeg er ikke sikker på, jeg bruger det efter hensigten, men det virker for mig så langt med den lille sæt af tests jeg hidtil har defineret).
Blanket.js integrerer med Qunit og sig vil røbe sig mig de faktiske linjer af JavaScript, der var – og endnu vigtigere – var ikke faktisk udføres under kører test. Dette er "dækning"-linjer, der udføres er omfattet af testen, mens andre ikke.
Mellem opsætning af god testcases og visning dækning, Vi kan reducere den risiko, at vores kode har skjulte defekter. Gode tider.
Qunit
Forudsat at du har din Visual Studio projekt oprettet, starte med at hente JavaScript-pakke fra http://qunitjs.com. Tilføje JavaScript og tilsvarende CSS til din løsning. Mine ser sådan ud:
Figur 1
Som du kan se, Jeg var ved hjælp af 1.13.0 på tidspunktet skrev jeg dette blogindlæg. Glem ikke at downloade og tilføje CSS-fil.
Der ud af måde, næste skridt er at skabe en form for test sele og reference Qunit bits. Jeg tester en masse funktioner i en scriptfil kaldet "QuizUtil.js", så jeg har oprettet en HTML-side kaldet "QuizUtil_test.html" som vist:
Figur 2
Her er koden:
<!DOCTYPE HTML> <HTML xmlns= "http://www.w3.org/ 1999/xhtml"> <hoved> <titel>QuizUtil test med Qunit</titel> <link rel= "stylesheet" href="../CSS/qunit-1.13.0.css" /> <script type= text/javascript"" src="QuizUtil.js" data-cover></script> <script type ="text/javascript" src ="qunit-1.13.0.js"></script> <script type ="text/javascript" src ="blanket.min.js"></script> <script> modul("getIDFromLookup"); test("QuizUtil getIDFromLookupField", funktion () { varians goodValue = "1;#Paul Galvin"; lig(getIDFromLookupField(goodValue) + 1, 2), "ID af [" + goodValue + "] + 1 bør være 2"; lig(getIDFromLookupField(ikke defineret), ikke defineret, "Udefineret inputargumentet skal returnere udefineret resultat."); lig(getIDFromLookupField(""), ikke defineret, "Tom inputargumentet skal returnere en udefineret værdi."); lig(getIDFromLookupField("gobbledigood3-thq;dkvn ada;skfja sdjfbvubvqrubqer0873407t534piutheqw;VN"), ikke defineret,"Skal altid returnere et resultat cabriolet til et heltal"); lig(getIDFromLookupField("2;#en anden person"), "2", "Kontrol [2;#en anden person]."); lig(getIDFromLookupField("9834524;#lang værdi"), "9834524", "Store værdi test."); notEqual(getIDFromLookupField("5;#nogen", 6), 6, "Test en notEqual (5 er ikke lig med 6 for denne prøve: [5;#nogen]"); }); modul("htmlEscape"); test("QuizUtil htmlEscape()", funktion () { lig(htmlEscape("<"), "<", "Undslippe et mindre end-operatør ('<')"); lig(htmlEscape("<div class = "someclass">Nogle tekst</div>"), "<div class ="someclass">Nogle tekst</div>", "Mere komplekse test streng."); }); modul("getDateAsCaml"); test("QuizUtil getDateAsCaml()", funktion () { lig(getDateAsCaml(nye Dato("12/31/2013")), "2013-12-31T:00:00:00", "Test hårdt kodet dato: [12/31/2013]"); lig(getDateAsCaml(nye Dato("01/05/2014")), "2014-01-05T:00:00:00", "Test hårdt kodet dato: [01/05/2014]"); lig(getDateAsCaml(nye Dato("01/31/2014")), "2014-01-31T:00:00:00", "Test hårdt kodet dato: [01/31/2014]"); lig(getTodayAsCaml(), getDateAsCaml(nye Dato()), "getTodayAsCaml() skal lige getDateAsCaml(ny dato())"); lig(getDateAsCaml("vrøvl værdi"), ikke defineret, "Prøv at få datoen for en sludder værdi."); lig(getDateAsCaml(ikke defineret), ikke defineret, "Prøv at få datoen for den [ikke defineret] dato."); }); modul("getParameterByName"); test("QuizUtil getParameterByName (fra forespørgselsstrengen.)", funktion () { lig(getParameterByName(ikke defineret), ikke defineret, "Prøv at få udefineret parameter skal returnere udefineret."); lig(getParameterByName("findes ikke"), ikke defineret, "Prøv at få værdi for parameteren, når vi ved, at parameteren ikke findes."); }); modul("Cookies"); test("QuizUtil forskellige cookie funktioner.", funktion () { lig(setCookie("test", "1", -1), getCookieValue("test"), "Få en cookie, jeg indstille bør arbejde."); lig(setCookie("anycookie", "1", -1), True, "Indstilling af en gyldig madlavning skal returnere 'sand'."); lig(setCookie("crazy Cookienavn !@#$%"%\^&*(()?/><.,", "1", -1), True, "Indstilling af en dårlig Cookienavn skal returnere 'false'."); lig(setCookie(ikke defineret, "1", -1), ikke defineret, "Passerer udefineret som cookie-navn."); lig(getCookieValue("findes ikke"), "", "Cookie ikke eksisterer test."); }); </script> </hoved> <kroppen> <div id= "qunit"></div> <div id= "qunit-armatur"></div> </kroppen> </HTML>
Der er flere ting der sker her:
- Refererer til min kode (QuizUtil.js)
- Refererer til Qunity.js
- Definere nogle moduler (getIDFromLookup, Cookies, m.fl.)
- Placere en <div> Hvis ID er "qunit".
Derefter, Jeg trække bare op denne side og du får noget som dette:
Figur 3
Hvis du ser øverst, du har et par muligheder, hvoraf to er interessante:
- Skjul bestået test: Temmelig indlysende. Kan hjælpe øjet bare se problemområderne og ikke en masse rod.
- Modul: (drop): Dette vil filtrere tests ned til netop disse grupper af tests du vil.
Hvad angår prøverne sig selv – et par kommentarer:
- Det er en selvfølge at du skal skrive din kode, så det er testbare i første omgang. Ved hjælp af værktøjet kan hjælpe med at håndhæve denne disciplin. For eksempel, Jeg havde en funktion kaldet "getTodayAsCaml()”. Dette er ikke meget testbare, da det tager ingen inputargumentet og teste det for ligestilling, Vi skal konstant opdatere test-kode for at afspejle den aktuelle dato. Jeg refactored det ved at tilføje en data input-parameteren derefter passerer den aktuelle dato, når jeg ønsker dags dato i CAML format.
- Qunit rammer dokumenterer sine egne test og det synes temmelig robust. Det kan gøre enkle ting som test for ligestilling og har også støtte til ajax stil opkald ("rigtige" eller hånet ved hjælp af din foretrukne mocker).
- Gå gennem processen også tvinger dig til at tænke gennem kanten tilfælde – hvad sker der med "Udefineret" eller null er gået ind i en funktion. Det gør det døde nemt at teste disse scenarier ud. Gode ting.
Dækning med Blanket.js
Blanket.js supplerer Qunit ved at spore de faktiske linjer kode, der udføres i løbet af kører din test. Det integrerer ret i Qunit så selv om det er en helt separat app, det spiller pænt-det ser virkelig ud som om det er en problemfri app.
Dette er blanket.js i aktion:
Figur 4
Figur 5
(Du faktisk nødt til at klikke på afkrydsningsfeltet "Aktiver dækning" øverst [Se figur 3] at muliggøre dette.)
De fremhævede linjer i figur 5 ikke er blevet henrettet af nogen af mine tests, så jeg nødt til at udtænke en test, der forårsager dem til at udføre hvis jeg ønsker fuld dækning.
Få blanket.js arbejde ved at følge disse trin:
- Downloade det fra http://blanketjs.org/.
- Føje det til dit projekt
- Opdatere din testside sele (QuizUtil_test.html i mit tilfælde) som følger:
- Reference koden
- Dekorere din <script> reference som denne:
<script type= text/javascript"" src="QuizUtil.js" data-cover></script>
Blanket.js opfanger attributten "data-cover" og gør sin magi. Det kroge til Qunit, opdaterer UI for at tilføje indstillingen "Aktiver dækning" og voila!
Resumé (TL; DR)
Brug Qunit til at skrive din prøvesager.
- Download det
- Føje det til dit projekt
- Skrive en test sele side
- Oprette din analyser
- Refactor nogle af jeres kode hen til blive testbare
- Være kreativ! Tænk på crazy, umuligt scenarier og teste dem alligevel.
Brug blanket.js til at sikre dækning
- Kontroller, at Qunit fungerer
- Download blanket.js og føje den til dit projekt
- Føje det til din testside sele:
- Tilføjelse af en henvisning til blanket.js
- Tilføje en "data-cover" attribut til din <script> Tag
- Køre din Qunit test.
Jeg har aldrig gjorde noget af dette før og havde nogle rudimentære ting arbejder i en håndfuld timer.
Happy test!
</slutningen>
Følg mig på kvidre på http://www.twitter.com/pagalvin