Share
I de två första artiklarna i denna serie tog vi en hög nivå på vilken enhetstestning som är och hur man applicerar den i samband med pluginutveckling. Naturligtvis finns det mer till WordPress än att skriva plugins, är det inte? En betydande del av ett WordPress-utvecklare jobb - för vissa är det mest betydande del - är temat utveckling.
Så i den här artikeln ska vi ta en titt på hur man utvecklar testbara teman. Närmare bestämt ska vi titta på hur teman är annorlunda än plugins och då ska vi skriva ett extremt enkelt tema som kommer att användas för att visa principerna för enhetstestning och som kan tillämpas i framtida utveckling.
Innan vi börjar skapa ett tema eller granskar någon kod är det viktigt att förstå skillnaden i tema och pluginutveckling. Först kan plugins skrivas på två sätt:
Båda metoderna gör samma sak: det vill säga de använder en samling funktioner och filter för att introducera ny funktionalitet till WordPress. Den primära skillnaden är hur funktionerna inkapslas.
Men när det gäller temat utveckling, finns det egentligen bara ett sätt att utveckla ett tema och det är med hjälp av en samling funktioner definierade i functions.php. Detta presenterar följande två utmaningar för att skriva enhetsprov för teman:
Eftersom goda teman använder en samling av filter och handlingar kommer vi att skapa ett tema som följer de bästa metoderna och eftersom betoningen av denna artikel finns i enhetstestningstema kommer mer tonvikt att läggas på att skriva testen snarare än skapa ett snyggt, mycket funktionellt tema.
Innan du kodar, låt oss initiera vårt projekts katalog. Vi måste konfigurera tematets skelett så, i din WordPress temakatalog, skapa en ny katalog för temat. Mine kallas Basic-tema. Lägg till följande filer (vi fyller ut dem senare):
Låt oss fortsätta och stubba ut stilarket så att WordPress känner igen temat och låter oss aktivera det från Dashboard. För att göra så lägg till följande kod:
/ * Tema Namn: Grundläggande Tema Tema URI: TODO Version: 1.0 Beskrivning: Ett grundläggande tema som används för att visa hur man skriver enhetstester för teman. Författare: Tom McFarlin Författare URI: http://tommcfarlin.com Licens: GNU General Public License v2.0 Licens URI: http://www.gnu.org/licenses/gpl-2.0.html * /
För att vara komplett, fortsätt och lägg till öppna och stänga PHP-taggar till början och slutet av din funktionsfil. Detta kommer att se till att vi har grunden lagd när vi börjar skriva temafunktioner senare i den här artikeln.
Och lägg till en ny katalog som heter tester. Här måste vi placera WordPress-testen.
Tidigare i denna serie gav jag en länk till WordPress-testen som finns på GitHub. Även om dessa tester är fina att använda, finns de senaste, automatiska, underhållna WordPress-testen i detta Subversion-arkiv.
Om du är en avancerad utvecklare rekommenderar jag att du checkar ut dessa test. Men om du bara har börjat med enhetsprovning - inget problem! Jag tillhandahåller all källkod - inklusive WordPress-testen - i ett GitHub-arkiv som du kan ladda ner, referera till och använda för egna projekt.
När testen är installerade ska ditt temans katalog se ut så här:
Eftersom PHPUnit måste köras från kommandoraden måste du öppna en terminal session (eller en kommandotolk), navigera till tester katalog, och du borde kunna köra dem med följande kommando (som exempel):
phpunit test / test_user_capabilities.php
Din terminal ska sedan mata ut något så här:
Se upp: Om du inte kan genomföra testerna, hänvisar du till den första artikeln i serien för att verifiera din konfiguration. Dessutom kan din körsträcka variera beroende på operativsystem, webbserver och lokal maskinkonfiguration. Om du slutar behöva göra något annat, vänligen dela dina anteckningar i kommentarerna för att hjälpa andra. Låt oss nu fortsätta aktivera temat i instrumentpanelen. Temaet ska aktivera (om inte, se till att du inte har några avvikande tecken i dina mallfiler). Om du försöker se temat kommer det naturligtvis att visa en vit skärm.
Innan vi skriver några tester, låt oss fortsätta och fylla i våra mallfiler med lite innehåll bara så att vi kan ha något dyka upp på fronten.
I header.php, lägg till följande kod:
<?php wp_title("); ?> >Detta är huvudet.
I index.php, lägg till följande kod:
Detta är innehållet.
Och i footer.php, lägg till följande kod:
Detta är sidfoten.
Enkelt, jag vet men det ger oss bara tillräckligt för att arbeta med när vi börjar skriva test. Spara ditt arbete, granska temat i webbläsaren och du bör se detta:
I din tester katalog, skapa en fil som heter test_basic_theme.php och stub ut filen så här:
Accentsconagua
// Inkludera funktionerna för temat include_once ('... /functions.php'); klass Test_Basic_Theme utökar WP_UnitTestCase // end class Ovan definierar vi en klass som används för att paketera alla våra tematesttester.
Låt oss först definiera inrätta metod. De inrätta Metoden är en funktion som tillhandahålls av WordPress Test-ramen och vi kan använda den för att skjuta vissa funktioner innan testen körs. Till exempel, när WordPress-testen körs, kör de mot standardtemat - det vill säga tjugo elva. I vårt fall vill vi köra testen mot vårt eget tema.
För att göra detta måste vi berätta för WordPress att faktiskt byta teman innan vi kör resten av våra test. Eftersom detta måste ske innan testen körs, måste det definieras i inrätta metod. Vettigt?
Så låt oss skriva vår inrätta metod:
funktion setUp () förälder :: setUp (); switch_theme ('Basic Theme', 'Basic Theme'); // slutkonfiguration Återigen, låt oss utföra våra test. Vi kan göra det genom att köra samma kommando som vi gjorde när vi först ställde in testet:
phpunit test / test_basic_theme.php
Tillåter att du har gjort allt korrekt, bör du faktiskt se ett fel när testet körs:
Felmeddelandet är klart, men: "Inga tester hittades i klassen "Test_Basic_Theme"". Så låt oss mildra det och skriva det första testet för temat. Det kan vara något utomordentligt enkelt men kom ihåg från föregående inlägg att vi inte vill testa bara Den optimala vägen, men också felbanan.
Som sådan måste vi testa att den grundläggande teman är aktiv och att tjugo elva inte är aktiv. För att göra detta använder vi assertTrue-metoden och assertFalse-metoden och vi gör det i samband med två funktioner. Ta en titt på koden nedan och uppdatera din testfil enligt följande:
funktion testActiveTheme () $ this-> assertTrue ('Basic Theme' == get_current_theme ()); // end testThemeInitialization function testInactiveTheme () $ this-> assertFalse ('Twenty Eleven' == get_current_theme ()); // end testInactiveTheme Återigen, kör testen och du bör se dem springa grönt. Trevligt, rätt?
Det här är en relativt enkel funktionalitet, så låt oss överväga några avancerade funktioner som vårt tema skulle kunna ha.
Utanför rutan innehåller inte Basic Theme jQuery så vi ska inkludera det med vårt tema. Om du kommer ihåg från de tidigare inläggen är den korrekta testmetoden för enheten som följer:
Så, låt oss göra just detta för jQuery.
Först måste vi skriva ett test för att avgöra om jQuery är laddad. Vi använder WordPress-funktionen wp_script_is. Eftersom temat går igenom den normala sidans livscykel i en webbläsare måste vi manuellt berätta för WordPress att ladda jQuery med hjälp av do_action-funktionen.
funktion testjQueryIsLoaded () $ this-> assertFalse (wp_script_is ('jquery')); do_action ('wp_enqueue_scripts'); $ this-> assertTrue (wp_script_is ('jquery')); // end testjQueryIsLoaded Innan vi går längre är det viktigt att notera här: Jag tycker inte om att placera flera påståenden i en enda funktion eftersom jag tycker att varje funktion borde tjäna för att testa ett enda syfte. Det finns dock undantag. Här måste vi se till att jQuery är inte laddad innan du ringer do_action.
Hur som helst, kör testet och det kommer att misslyckas. Så vi måste lägga till koden till functions.php Det kommer att se till att jQuery läggs till i vårt tema. För att göra det, inkludera följande funktion i din funktionsfil:
funktion basic_add_jquery () wp_enqueue_script ('jquery'); // än basic_remove_jquery add_action ('wp_enqueue_scripts', 'basic_add_jquery'); Slutligen kör testet och det ska vara grönt. Lätt nog, är det inte?
Låt oss säga att vi vill inkludera en standardmetabeskrivning på hemsidan. I det enklaste fallet blir det inte mer än bloggens beskrivning. Så, genom att följa med vår metod som beskrivs ovan, låt oss introducera en funktion för att testa att metabeskrivningssträngen som läggs till huvudelementet matchar vad vi förväntar oss:
funktionstestBasicMetaDescription () $ meta_description = ''; $ this-> expectOutputString ($ meta_description, basic_meta_description ()); // end testBasicMetaDescription
Kör det - det kommer att misslyckas. Observera att jag inte använder standarden assertTrue, assertFalse funktioner - det kommer att finnas mer information om detta på ett ögonblick. Låt oss nu introducera följande funktion i functions.php:
funktion basic_meta_description () echo ''; // end basic_meta_description add_action ('wp_head', 'basic_meta_description'); Observera att denna funktion hakar i wp_head verkan. För att skriva metabeskrivningen ut i huvudelementet måste vi eko strängen snarare än lämna tillbaka tråden.
Observera att i testet ovan använder vi expectOutputString. Detta är användbart när vi behöver utvärdera en funktion som ECHO: s en sträng (snarare än avkastning en sträng). Sedan wp_head Åtgärden kommer att returnera en betydande mängd data (det vill säga hela huvudelementet), vi behöver verkligen bara utvärdera metabeskrivningen som returneras. Och det är därför snarare än att ringa do_action ('wp_head'), Jag ringer helt enkelt själva funktionen och utvärderar resultatet mot vad jag förväntar mig att ha.
Återigen kör PHPUnit och dina test ska alla passera.
Klart har vi bara repat ytan på vilken enhetstestning som kan göras för vår temat utveckling. Det finns fortfarande mycket som kan testas - vi har inte ens tittat på att testa The Loop, olika sätt att utvärdera postformat, eller till och med hur man granskar kommentarer.
Kom ihåg det här är en nybörjare guide och de tre artiklarna täcker mycket mark.
Oavsett, principerna är desamma: Det handlar om att se till att du programmatiskt avfyrar lämplig funktion eller åtgärd och utvärderar dess produktion i både förväntade och oväntade fall.
Slutligen kan du hitta hela projektet tillsammans med dokumenterade funktioner i det här GitHub-arkivet.
Här är en sammanfattning av resurserna som används i den här artikeln:
assertTrueassertFalsewp_script_isdo_actionwp_headexpectOutputString