Att skriva enhetstester med PHPUnit, del 2: The Tear Down
I slutet av förra månaden började jag prata om att skriva enhetstester i PHPUnit för WordPress-baserad kod. Detta inkluderade i första hand idén att ställa in PHPUnit, setUp- funktionen och skriva grundläggande tester.
Detta diskuterade dock inte vad jag vet om tearDown- funktionen som fortfarande är en viktig egenskap för att skriva med tester. Dessutom finns det två sätt att överväga att skriva tester för WordPress-projekt.
Nämligen:
- skriva tester specifikt för plugins och applikationslagerfunktioner,
- köra enhetstester mot WordPress-applikationen.
Innan jag går vidare med det här inlägget rekommenderar jag dock att du tar reda på vad jag hittills har tagit upp. Detta inkluderar följande inlägg:
- En WordPress-utvecklingsmiljö (med en pakethanterare)
- En IDE för WordPress-utveckling
- Arbeta med användarinställningar i Visual Studio Code
- Skriva enhetstester med PHPUnit, del 1: Installationen
När du har gjort det, återvänd till det här inlägget och låt oss fortsätta diskutera tearDown-funktionen och hur enhetstester i WordPress-sammanhang faktiskt ser ut.
Enhetstest med PHPUnit, del 2: The Tear Down
Innan du går vidare, kom ihåg att utvecklare ofta behandlar setUp- funktionen som konstruktorn och tearDown- funktionen som en destruktor; kom dock ihåg att det senare inte alltid behövs.
Här är en bra tumregel att komma ihåg:
- Allt som en testfunktion behöver anropar setUp- funktionen så att nödvändiga klasser behövs.
- TearDown -funktionen behövs inte alltid eftersom setUp- funktionen kan återinitiera en klass.
Så vad betyder detta för tearDown- funktionen om den inte återställer data som skapats under inställningsfunktionen?
1 TearDown-funktionen
Det bästa rådet jag kan ge kring tearDown- funktionen är att den ska användas om något sätts upp under något av testerna som är kvar.
Det här kan vara något som skrivs till en databas, något som skrivs till en logg, eller, mer allmänt, något som skrivs till hårddisken.
Således, om ett test skriver en post eller en fil, kommer tearDown- metoden att köras efter ett test och bör ta bort det test som registrerats på enheten som inte är en del av testet men som inte behövs permanent för nästa test eller som ska städas upp efter sig.
Så på sätt och vis är det som en förstörare, men om du aldrig har använt ett språk som har en destruktor verkar den nomenklaturen antingen irrelevant eller inte vettig.
En destruktor är en speciell medlemsfunktion som anropas när ett objekts livstid tar slut. Syftet med förstöraren är att frigöra de resurser som föremålet kan ha förvärvat under sin livstid.
Därför kanske det är bättre att helt enkelt tänka på funktionen som ett sätt att städa upp efter ett test (och inte i betydelsen att ställa in en variabel lika med null eftersom setUp- funktionen kan göra det).
2 enhetstester för WordPress-projekt
När vi skriver enhetstester för WordPress-projekt måste vi se till att vi är tydliga med vilken typ av enhetstester vi pratar om.
Till exempel, vad jag kommer att hänvisa till som klassiska eller standard enhetstester följer metoden "testdriven utveckling" som jag kommer att prata om om ett ögonblick. Å andra sidan har WordPress en egen uppsättning enhetstester för teman och liknande som jag också kommer att prata om lite längre fram i detta inlägg.
Men för det här avsnittet tänkte jag att det kan vara bra att prata lite om det förra snarare än det senare så att du kan se hur det här kan fungera.
I exemplet nedan skriver jag tester mot ett plugin som är ansvarigt för att kommunicera med ett tredje parts API. Denna speciella plugin kräver ett användarnamn och lösenord eller ett API och det vill vi försäkra oss om att det, för detta inläggs syften, hämtar ett fel korrekt när testet körs.
Observera att när du läser igenom den här koden kommer du att se mig prata lite om reflektion. Jag ska göra ett helt inlägg om PHP Reflection snart så det kommer att belysa detta.
För koden nedan antar du dock att det är ett sätt som vi kan få tillgång till egenskaper som annars är markerade som privata.
Minns från det senaste inlägget i den här serien, vi hade ett första test som såg ut så här:
Observera dock att det i det här testet inte finns någon tearDown- funktion som är vettig, eller hur? När allt kommer omkring skrivs ingenting till en databas eller till en fil.
Men låt oss säga att vi vill introducera ett testfall som kommer att ha ett filnamn, innehåll och som kommer att skriva innehållet till filen. I det här fallet kommer det att vara statisk data men detta kan tekniskt sett vara vad som helst som är skrivet till disken.
1 Ställa in testet
Först vill vi ställa in testet genom att definiera filnamnet, innehållet i filen och förbereda egenskaperna.
Lätt nog, eller hur?
2 Skriv och läs data
Därefter vill vi skriva data, läsa data och hävda att innehållet är detsamma.
Vid det här laget, om du kör testet (som jag ännu inte har tekniskt sett hur man gör), kommer du att märka att testFile.txt fortfarande finns på ditt system.
3 Använda tearDown
Slutligen måste vi arbeta med tearDown- metoden för att se till att filen raderas efter slutförandet av enhetstestet. Så här kan det se ut om du har implementerat din kod som det du ser ovan.
Lägg märke till att i tearDown- metoden kontrollerar jag först om en file_exists. Detta beror på att om du helt enkelt försöker ta bort länken till en fil som inte finns, kommer du att få ett felmeddelande när du kör dina tester, för om tearDown är närvarande kommer den att försöka ta bort något efter varje enskild testfunktion. Och om filen inte finns finns det inget för den att radera, och därför kommer det att resultera i ett problem.
Så i ett försök att skriva kod defensivt tror jag att det är ansvarigt för att kontrollera om filen finns innan du faktiskt försöker ta bort den.
3 Operationsordning
När det kommer till ren enhetstestning kommer du normalt att läsa detta i termer av testdriven utveckling. Detta är ett stort ämne i och för sig; men det är värt att nämna här om du väljer att forska vidare i det och till och med implementera det i dina utvecklingsarbeten.
Den allmänna idén bakom detta tillvägagångssätt kallas ofta för "röd-grön-upprepa." Och jag förnekar det inte, det är något med detta tillvägagångssätt. Det låter dig nämligen som utvecklare skriva kod som du förväntar dig att den ska fungera innan du faktiskt skriver koden.
Psykologin bakom det är denna: Om du vet hur koden fungerar, är det mer sannolikt att du skriver tester som klarar; Om du skriver tester för hur koden ska fungera bör du skriva bättre kod.
Tyvärr har vi inte alltid den lyxen. Men det betyder inte att vi ska kasta ut det ökända barnet med vattnet. Istället är jag av den tankegången att man ska skriva prov när man kan och skriva koden efteråt; annars skriv dina tester efter din kod.
I slutändan kommer det att vara bättre att ha tester på plats oavsett än inga tester alls.
4 Testa med WordPress
När det kommer till enhetstestning i WordPress finns det några saker som du förmodligen har snubblat över. Ibland är innehållet en felaktig benämning eller kan till och med vara missvisande när det gäller "enhetstestning i WordPress."
Som exempel, det finns två saker värda att notera:
- Temaenhetstestet. Denna speciella uppsättning innehåll är tänkt att hjälpa temautvecklare att testa alla större och mindre fall för sina teman. Det finns inte automatiserade verktyg, till exempel, som du skulle använda som i det vi har diskuterat ovan.
- Automatiserad testning. WordPress levereras med en egen uppsättning enhetstester så att vi inte behöver skriva tester mot det mesta av funktionaliteten i WordPress (som huruvida API-funktioner fungerar som förväntat eller inte). Detta gör att vi kan fokusera på att skriva enhetstester för vår egen domänlogik.
- Plugin-enhetstester. Om du har använt WP-CLI (eller är intresserad av det), så har du förmodligen läst den här sidan eller till och med använt det här verktyget. Det är användbart, men det är också inriktat på specifika aspekter av att testa WordPress-plugins.
Allt ovanstående är användbar information, och jag säger inte att den ska ignoreras. Istället bör den kombineras med resten av informationen som används i det här inlägget.
Köra enhetstester
I nästa inlägg kommer jag att gå igenom allt du behöver veta för att ställa in en XML-fil som kommer att informera PHPUnit om var testerna finns och hur man kör dem.
Men för nu, granska koden som finns i det här inlägget och förbered dig på att bygga vidare på den i nästa inlägg i den här serien.