Share
I den senaste artikeln började vi prata om teorin om enhetstestning i WordPress. I synnerhet har vi granskat vårt arbete med enhetstestningstema och plugins började sedan diskutera enheter av kod, hur det påverkar vår testning och vi granskade enhetstester i den större världen av mjukvaruutveckling.
Vi kommer att fortsätta diskutera teorin om enhetstestning i WordPress, men kommer att göra det genom perspektivet på hur det kan hjälpa till att identifiera problem, köra arkitektur, dokumentera projektet och mer.
Minns från tidigare i denna serie, att det traditionella sättet att göra enhetsprovning är detta:
Ja, det första steget är lite dogmatiskt. Varför slösa minuter kör något du vet kommer att misslyckas, eller hur? Ändå får du idén. Men när du börjar tillämpa den här tekniken för utveckling, kommer du att upptäcka att du kommer att utveckla en viss rytm för att skriva din kod och det är en del av hela målet.
Men det är bara hälften av det - enhetsprovning kan faktiskt hjälpa dig att upptäcka problem tidigare i utvecklingen.
För att förstå, är det troligen bäst att återvända till idén.
Låt oss säga att du arbetar med en funktion för ett WordPress-baserat projekt där du ska tillåta användare att skapa ett användarkonto utan att logga in på WordPress-instrumentpanelen. Det förutsätter att du har en sidmallinstallation för att hantera registrering, nödvändig validering på plats och koden för att generera lösenord och e-postmeddelanden.
Du laddar sidan upp i din webbläsare, försöker skapa några användare - vissa med samma e-postadress, vissa med felaktiga lösenord, vissa med olagliga tecken, etc. Du får poängen - det finns n antal sätt att validera att passera och att misslyckas. Detta är grovt! Det innebär att varje gång användarregistreringsfunktionen ändras måste du utföra samma n-nummer registreringar för att se till att ingenting är trasigt.
Eller du kan skriva en serie test för att ta hand om det och köra dem alla varje gång koden ändras.
Så, ja, skriva enhetstest kan ta mycket tid framåt men titta på hur mycket tid som sparas varje gång du ändrar en kodenhet. Det är väl värt det och det kan hjälpa till att identifiera problem tidigt - det vill säga innan det släpptes i produktion - det kunde ha blivit missat eftersom någon glömde att simulera en permutation av testet.
När det gäller att skriva enhetstest förbättrar du inte bara kvaliteten på din kod genom att se till att den faktiskt fungerar, men du tillhandahåller i sin tur utvecklarorienterad dokumentation.
Om du testar enhetens funktionalitet som du bygger på din produkt, kommer du att tillhandahålla dokumentation för hur funktionerna är avsedda att fungera, när de ska misslyckas och när de ska passera.
Det finns några antaganden som följer med detta: Specifikt att du logiskt namnger och grupperar dina funktioner och deras associerade test och att du testar varje funktion korrekt.
Genom PHPUnit gör WordPress Unit Tests det enkelt att utföra påståenden som är lätta att läsa. Du anger helt enkelt assertTrue, assertFalse eller andra påståenden som finns tillgängliga på de funktioner som komponerar ditt projekt.
Följande med vårt exempel ovan betyder det att du kan skriva en funktion för att se till att användarregistreringsfunktionen misslyckas när du försöker registrera dig med en tom e-postadress:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Ett enkelt exempel kanske, men punkten förblir: Din kod blir självdokumentation och det kräver bara att du skriver tydliga enhetsprov.
Kanske är en av de mest diskreta fördelarna med enhetstestning att den kan hjälpa till att driva arkitekturen i ditt projekt. Typiskt kan utveckling av temat eller plugin starta på två sätt:
Dessa är inte inneboende dåliga, men jag tror att de är svaga (och jag är den första som medger att jag har gjort både mer än jag skulle vilja dela!). Men "skriv kod" -steget förutsätter mycket, gör det inte?
För alla som har skrivit kod i gott om tid är du alldeles för bekant att du slutar slå på den punkten där du inser, "Åh ... det tänkte jag inte på."
Om du har tur så betyder det oftast att du kan skriva en hjälparätt eller en annan villkorad för att hantera det fall du försummade, men i värsta fall betyder det att du kanske måste omarbeta hela din klass eller hela din uppsättning funktioner till tillgodose detta problem.
Enhetstestning, men inte perfekt, kan bidra till att mildra detta.
Tänk på att du från och med början noterar alla funktioner som du vill ha ditt tema eller plugin att erbjuda. Du har ännu inte skrivit någon kod, men kanske har du någon typ av skiss av användargränssnittet och / eller en uppsättning klassdiagram.
Därefter börjar du skriva ut de tester som du ska skriva för att testa ditt projekt. Kom ihåg att en del av enhetsprovningen bryter ner koden till den allra största atomenheten, så du är uppgift att skriva enhetsprov för var och en av dessa, hm, enheter.
På grund av enhetstestningens karaktär tänker du naturligtvis på din kod annorlunda: i stället för "skrivkod" tänker du "skriva test" och eftersom du måste tänka på en mer atomnivå kan du Det hjälper inte att överväga fransfall som så ofta klumpas i "skrivkod".
Som utvecklare är vi alltför bekväma med att använda konventioner som ständigt förstärker att vi skriver kod. Därmed menar jag att vi brukar ge förkortade variabla namn, kryptiska funktionsnamn och klassnamn som kanske inte betyder någonting för någon utanför dig själv eller laget som arbetar med ditt projekt.
Enhetstestning är inte nödvändigtvis nyckeln till skrivkod som är lättare att läsa, men det kan gå lite längre för att hjälpa till att ge renare funktionsnamn.
Minns från den första programmeringsboken du läser, den första datavetenskapsklassen du tog, eller den första delen av öppen källkod du såg, metodnamn är vanligtvis verb. Varför borde de inte vara? Metoder är sätt att inkapsla kod som gör saker. Men när vi jobbar på projekt längre och längre blir vi slöseri och slöseri och vår kod går från "register_user_and_email_password ()"till"nytt konto()".
Självklart är den förstnämnda renare än den senare, men om vi strävar efter kvalitetsenhetstestning och vi vill se till att våra enhetstester är lätta att läsa och för att de ska vara lätta att läsa måste våra funktionsnamn vara lätt att läsa.
Är det inte lättare att läsa:
$ this-> assertFalse (register_user_and_email_password (")); Istället för det här?
$ this-> assertFalse (new_account (")); Återigen kanske detta är ett enkelt exempel, men principen förblir: Skriva bra enhetstest för att hjälpa dig själv att dokumentera koden som driver språket i dina funktioner.
Vi har pratat om grunderna för enhetstestning samt de viktigaste fördelarna, men vi har ännu inte diskuterat nackdelarna med enhetstestning och vi har inte ens tittat på hur man införlivar det i vårt arbetsflöde.
Så i nästa artikel försöker vi göra just det.
