Skriva enhetstester med PHPUnit, del 1: Installationen

Senaste uppdateringen nov 26, 2022

Innehåll

Enhetstest med PHPUnit, del 1: Konfigurationen

Tidigare denna månad började vi titta på att installera PHPUnit i Visual Studio Code med det slutliga målet att lära sig hur man skriver enhetstester för våra WordPress-baserade projekt.

För detta ändamål förutsätter det här inlägget att du har läst följande inlägg och det förutsätter att du har kommit ikapp med en handfull tidigare inlägg:

Och, naturligtvis, installera PHPUnit i Visual Studio Code enligt länken ovan. När det är gjort är vi redo att fortsätta. Men en sak att tänka på är att det här kvällen blir en traditionell eller en omfattande kurs i att skriva enhetsprov.

Istället handlar det om att skriva enhetstester för WordPress-projekt.

Enhetstest med PHPUnit, del 1: Konfigurationen

Innan jag går för djupt in på det här vill jag vara tydlig med att det här inte så mycket är ett inlägg i testdriven utveckling utan ett inlägg som lägger grunden för att förstå att skriva enhetstester. Och sedan, i slutändan, kommer vi att arbeta för att skriva enhetstester för vår kod.

För de av er som har läst något tidigare om enhetstestning så vet ni att skriva enhetstester är ett ämne som det finns mycket information om och det här inlägget kommer inte att försöka täcka allt detta. Istället kommer det att ta ett mer pragmatiskt tillvägagångssätt för att skriva enhetstester mot WordPress-baserade plugins, webbapplikationer och liknande.

1 Skriva enhetstester

När du först börjar skriva enhetstester kommer du att presenteras med både idén om installations- och nedtagningsmetoderna. Detta är vanligt i PHPUnit (som med andra testramar). Det finns några saker med dessa två särskilda metoder som ofta orsakar problem.

Kort sagt, människor behandlar funktionerna så här:

setUp är som konstruktorn där du instansierar din klass och sedan förbereder du allt du behöver för ditt test inklusive objektet som ska testas, den data som behövs och så vidare.
tearDown är förstöraren där du återställer allt och sedan gör dig av med dina föremål. Detta är vanligtvis vanligare i kompilerade språk men det är inte heller att missa inom PHPUnit.

Och även om jag fullt ut kan förstå detta så är det inte alltid så. Jag talar av erfarenhet här också. Istället är det här själva frasenhetstestningen kommer ifrån. Det handlar om att testa enheters kodkod och att göra det på ett rent, kortfattat sätt.

Så vad är dessa metoder för något? Detta kan vara en särskilt svår vana att bryta eller till och med konceptuell modell att bryta när du först kommer in i processen. För det ändamålet vill jag undersöka syftet med varje metod och sedan hur man kan närma sig detta när man arbetar med WordPress-baserade projekt.

Och som vanligt kommer jag att sträva efter att hålla detta så enkelt och pragmatiskt som möjligt. Jag är mycket mindre intresserad av teorin bakom vissa saker än jag är av hur den kan tjäna både min verksamhet och mina projekt väl. (Detta är naturligtvis inte för att bortse från teori, men det finns en tid inte en plats för det och den här bloggen är inte det.)

2 Inställningsfunktionen

Även om jag börjar med en kort diskussion om setUp- metoden, är det viktigt att komma ihåg att dess systerfunktion (som vissa anser det) inte alltid behövs.

Till exempel, om du skriver kod där allt du gör är att instansiera ett objekt eller en uppsättning objekt, kanske inte tearDown- metoden behövs. Jag kommer att gå in mer i detalj om detta i nästa avsnitt.

Med det sagt, låt oss säga att du har en klass som är ansvarig för att köra lite domänlogik. Kom ihåg att i detta inläggs syfte är vi inte oroliga för kod som gör saker som WordPress gör naturligt och som redan har sin egen uppsättning tester.

Med det menar jag att vi är oroliga för kod som fungerar specifikt inom en problemdomän. Till exempel kanske vi är intresserade av att skriva en klass som cachar data till databasen. En av de delar av information som är ansvarig för cachelagring av information är hur länge data ska vara cache. Således skulle en kandidat för enhetstestet göra med att vi kan ställa in och ändra tiden, eller hur?

Visserligen är denna data kanske hårdkodad, men för exempel, låt oss anta något annat. Detta innebär följande:

Vi har en klass som fungerar som vår cache,
Klassen upprätthåller en bit av instansdata för hur länge cachen ska vara inställd,
Cachetiden kan ställas in från tredjepartsklasser,
Cachetiden kan läsas från tredjepartsklasser.

Detta innebär att ett enhetstest skulle omfatta:

Ställer upp klassen,
Definiera ett värde,
Att hävda att värdet som definierades är som förväntat,,
Ändra värdet,
Att hävda värdet som ändrades uppdaterades.

Så grundklassen kan se ut ungefär så här (all dokumentation lämnas utanför klassen i syfte att hålla koden så kortfattad som möjligt):

Observera att vi som standard har cachetiden inställd på 12 timmar (i sekunder). Klassen stödjer förmågan att både ändra och läsa av varaktigheten.

Det betyder att vi kan skriva tester som testar:

om det initiala värdet är det förväntade,
om det nya värdet är vad som förväntades (och att det skriver över det initiala värdet)

En av sakerna jag skulle vilja påpeka i ovanstående kod är att du kan läsa att varje test bör ha ett enda påstående medan testNewDuration uppenbarligen har två påståenden.

Jag tenderar att ta tanken på ett påstående per test som en tumregel. Till exempel, i det här fallet, vill jag hävda att det initiala värdet skrivs över eller inte lagras någonstans och det nya värdet lagras.

Detta kanske inte alltid är fallet, så du kan behöva behandla dessa typer av situationer med försiktighet.

Som du kan se har detta inget med WordPress att göra; det har dock att göra med att testa logik specifikt relaterad till domänen till hands. Nämligen cachens varaktighet. Och det här är vad kärnan i enhetstestning handlar om: Testa det logiska beteendet hos kodenheter för att säkerställa att vi har saker som fungerar som förväntat.

Och beroende på när du skriver den här koden kan du ha misslyckade tester. Detta kan i slutändan hjälpa till med klassdesign, men det är ett annat ämne och inte ett som är en del av det här inlägget.

Kör testerna

När proven väl är skrivna är det viktigt att kunna utföra dem för att se om de klarar, om de misslyckas, vad som godkänns och vad som inte går. Men vi är inte klara än. Jag vill ge en heltäckande titt på enhetstestning i WordPress-sammanhang och det handlar om att diskutera vad WordPress tillhandahåller, vad det inte gör, några missuppfattningar och hur man kör dessa tester i terminalen eller i Visual Studio Code.

I nästa inlägg i den här serien kommer vi att titta på tearDown- funktionen och hur (och när) den ska användas, när den behövs, när den inte är det, och sedan ska vi titta lite på kring enheten testa i WordPress i allmänhet.

I slutändan arbetar vi för att få en fullständig bild av hur man gör detta och hur man gör det rätt. Men det är viktigt att lägga grunden för det och att göra det under ett par inlägg är lättare än i ett monolitiskt inlägg.

Så att undersöka tearDown(), dess användning och hur man utför tester från kommandoraden kommer att vara ämnet för nästa inlägg i den här serien.

Inspelningskälla: tommcfarlin.com