Share
In de eerste twee artikelen in deze serie hebben we op hoog niveau gekeken naar wat eenheidstesten zijn en hoe deze kunnen worden toegepast in de context van de ontwikkeling van plug-ins. Natuurlijk is er meer bij WordPress dan het schrijven van plug-ins, is het niet? Een aanzienlijk deel van een WordPress-ontwikkelaarsjob - voor sommigen is het de meest belangrijk onderdeel - is thema-ontwikkeling.
Dus in dit artikel gaan we kijken hoe we testbare thema's kunnen ontwikkelen. Concreet gaan we kijken hoe thema's anders zijn dan plug-ins en dan gaan we een uiterst eenvoudig thema schrijven dat zal worden gebruikt om de principes van unit-testing aan te tonen en dat kan worden toegepast in toekomstige ontwikkelingen.
Voordat we aan de slag gaan met het maken van een thema of het bekijken van een code, is het belangrijk om het verschil in de ontwikkeling van thema's en plug-ins te begrijpen. Ten eerste kunnen plug-ins op twee manieren worden geschreven:
Beide methoden doen hetzelfde: ze gebruiken een verzameling functies en filters om nieuwe functionaliteit aan WordPress te introduceren. Het belangrijkste verschil is hoe de functies zijn ingekapseld.
Maar als het gaat om thema-ontwikkeling, is er eigenlijk maar één manier om een thema te ontwikkelen en dat is door een verzameling functies te gebruiken die zijn gedefinieerd in functions.php. Dit presenteert de volgende twee uitdagingen voor het schrijven van eenheidstests voor thema's:
Omdat goede thema's een verzameling filters en acties gebruiken, gaan we een thema maken dat deze beste praktijken volgt en omdat de nadruk van dit specifieke artikel ligt op unit-testingthema's, zal meer nadruk worden gelegd op het schrijven van de tests in plaats van het creëren van een goed uitziend, zeer functioneel thema.
Laten we vóór het coderen de directory van ons project initialiseren. We moeten het skelet van het thema zo instellen dat je in je WordPress themamap een nieuwe map voor het thema maakt. De mijne wordt genoemd Basic-Theme. Voeg de volgende bestanden toe (we zullen ze later invullen):
Laten we doorgaan en het stylesheet wegstrepen zodat WordPress het thema herkent en ons in staat stelt om het vanuit het Dashboard te activeren. Voeg hiervoor de volgende code toe:
/ * Theme Name: Basic Theme Theme URI: TODO Versie: 1.0 Beschrijving: Een basisthema om te laten zien hoe eenheidstests voor thema's kunnen worden geschreven. Auteur: Tom McFarlin Auteur URI: http://tommcfarlin.com Licentie: GNU General Public License v2.0 License URI: http://www.gnu.org/licenses/gpl-2.0.html * /
Om compleet te zijn, ga je gang en voeg je PHP-tags openen en sluiten toe aan het begin en het einde van je functiedossier. Dit zal ervoor zorgen dat we de basis leggen wanneer we later in dit artikel themafuncties beginnen te schrijven.
En voeg een nieuwe map toe genaamd testen. Hier moeten we de WordPress-tests plaatsen.
Eerder in deze reeks heb ik een link verstrekt naar de WordPress-tests op GitHub. Hoewel deze tests prima te gebruiken zijn, bevinden de meest recente door Autommatic onderhouden WordPress-tests zich in deze Subversion-repository.
Als u een ervaren ontwikkelaar bent, raad ik u aan deze tests uit te proberen; als je echter net begint met het testen van eenheden - geen probleem! Ik verstrek alle broncode - inclusief de WordPress-tests - in een GitHub-repository die je kunt downloaden, gebruiken en gebruiken voor je eigen projecten..
Zodra de tests zijn geïnstalleerd, ziet de directory van uw thema er als volgt uit:
Omdat PHPUnit vanaf de opdrachtregel moet worden uitgevoerd, moet u een terminalsessie (of een opdrachtprompt) openen, naar de testen directory, en u zou ze moeten kunnen uitvoeren met behulp van de volgende opdracht (als voorbeeld):
phpunit tests / test_user_capabilities.php
Uw terminal zou dan iets als dit moeten uitvoeren:
Leest omhoog: Als u de tests niet kunt uitvoeren, raadpleegt u het eerste artikel in de serie om uw configuratie te controleren. Bovendien kan uw kilometerstand variëren op basis van uw besturingssysteem, webserver en lokale machineconfiguratie. Als je uiteindelijk iets anders moet doen, deel je opmerkingen dan in de opmerkingen om anderen te helpen. Laten we op dit punt doorgaan en het thema activeren in het Dashboard. Het thema zou moeten activeren (als dat niet het geval is, zorg er dan voor dat je geen losse karakters in je sjabloonbestanden hebt). Als u probeert het thema te bekijken, zal het natuurlijk een wit scherm weergeven.
Voordat we tests schrijven, gaan we door met onze sjabloonbestanden te vullen met een klein beetje inhoud, zodat we die kunnen hebben iets op de frontend verschijnen.
In header.php, voeg de volgende code toe:
<?php wp_title("); ?> >Dit is de kop.
In index.php, voeg de volgende code toe:
Dit is de inhoud.
En in footer.php, voeg de volgende code toe:
Dit is het voettekstje.
Eenvoudig, ik weet het, maar dit geeft ons net genoeg om mee te werken wanneer we beginnen met het schrijven van tests. Sla je werk op, bekijk het thema in de browser en je zou dit moeten zien:
In uw testen map, maak een bestand aan met de naam test_basic_theme.php en scan het bestand er als volgt uit:
Accentsconagua
// Neem de functies voor het thema include_once ('... /functions.php') op; klasse Test_Basic_Theme verlengt WP_UnitTestCase // eindklasse Hierboven definiëren we een klasse die wordt gebruikt om alle eenheidstests van ons thema in te pakken.
Laten we eerst de opstelling methode. De opstelling methode is een functie die wordt geboden door het WordPress-testraamwerk en we kunnen het gebruiken om bepaalde functies af te vuren voordat de tests worden uitgevoerd. Wanneer de WordPress-tests bijvoorbeeld worden uitgevoerd, worden ze tegen het standaardthema uitgevoerd, dat wil zeggen: Twenty Eleven. In ons geval willen we de tests uitvoeren tegen ons eigen thema.
Om dit te doen, moeten we WordPress vertellen om daadwerkelijk van thema te veranderen voordat de rest van onze tests worden uitgevoerd. Aangezien dit moet gebeuren voordat de tests worden uitgevoerd, moet dit worden gedefinieerd in de opstelling methode. Logisch?
Dus laten we onze schrijven opstelling methode:
functie setUp () parent :: setUp (); switch_theme ('Basisthema', 'Basisthema'); // einde installatie Nogmaals, laten we onze tests uitvoeren. We kunnen dit doen door dezelfde opdracht uit te voeren als toen we de test aanvankelijk opzetten:
phpunit tests / test_basic_theme.php
Als je toelaat dat je alles goed hebt gedaan, zou je een fout moeten zien wanneer de test wordt uitgevoerd:
De foutmelding is echter duidelijk: "Geen tests gevonden in klasse "Test_Basic_Theme"Dus laten we dit verminderen en de eerste test voor het thema schrijven. Het kan iets buitengewoons eenvoudig zijn maar onthoud van de vorige post dat we niet willen testen net het optimale pad, maar ook het faalpad.
Als zodanig moeten we testen of het basisthema actief is en dat Twenty Eleven niet actief is. Om dit te doen, zullen we de assertTrue-methode en de assertFalse-methode gebruiken, en dat doen we in de context van twee functies. Bekijk de onderstaande code en werk uw testbestand dienovereenkomstig bij:
function testActiveTheme () $ this-> assertTrue ('Basic Theme' == get_current_theme ()); // end testThemeInitialization function testInactiveTheme () $ this-> assertFalse ('Twenty Eleven' == get_current_theme ()); // end testInactiveTheme Voer de tests opnieuw uit en u zou ze groen moeten zien te zien zijn. Mooi toch?
Dit is een relatief eenvoudige functionaliteit, dus laten we een paar geavanceerde functies overwegen die ons thema zou kunnen hebben.
Standaard bevat jQuery geen basiskennis, dus we gaan het opnemen in ons thema. Als je je herinnert uit de eerdere berichten, is de juiste methode voor het testen van eenheden als volgt:
Dus laten we dit precies doen voor jQuery.
Eerst moeten we een test schrijven om te bepalen of jQuery is geladen. We zullen de WordPress-functie wp_script_is gebruiken. Aangezien het thema de normale levenscyclus van de pagina in een browser doorloopt, moeten we WordPress handmatig vertellen dat jQuery moet worden geladen met behulp van de do_action-functie.
function testjQueryIsLoaded () $ this-> assertFalse (wp_script_is ('jquery')); do_action ('wp_enqueue_scripts'); $ this-> assertTrue (wp_script_is ('jquery')); // end testjQueryIsLoaded Voordat we verder gaan, is er iets belangrijk om op te merken: ik vind het niet leuk om meerdere beweringen in een enkele functie te plaatsen omdat ik denk dat elke functie moet dienen om één doel te testen; er zijn echter uitzonderingen. Hier moeten we ervoor zorgen dat jQuery is niet geladen voor het bellen do_action.
Hoe dan ook, voer de test uit en het zal mislukken. Dus we moeten de code toevoegen functions.php dat zorgt ervoor dat jQuery aan ons thema wordt toegevoegd. Om dit te doen, neemt u de volgende functie op in uw functiesbestand:
function basic_add_jquery () wp_enqueue_script ('jQuery'); // end basic_remove_jquery add_action ('wp_enqueue_scripts', 'basic_add_jquery'); Voer tot slot de test uit en deze moet groen zijn. Makkelijk genoeg, is het niet?
Laten we zeggen dat we een standaard metabeschrijving op de startpagina willen opnemen. In het eenvoudigste geval is het niets meer dan de beschrijving van de blog. Dus laten we, in navolging van onze hierboven uiteengezette methodologie, een functie introduceren om te testen dat de metabeschrijvingstekenreeks die aan het hoofdelement is toegevoegd, overeenkomt met wat we verwachten:
function testBasicMetaDescription () $ meta_description = ''; $ this-> expectOutputString ($ meta_description, basic_meta_description ()); // end testBasicMetaDescription
Voer het uit - het zal mislukken. Merk op dat ik de standaard niet gebruik assertTrue, assertFalse functies - daarover zullen binnenkort meer details beschikbaar zijn. Laten we nu de volgende functie introduceren in functions.php:
function basic_meta_description () echo ''; // end basic_meta_description add_action ('wp_head', 'basic_meta_description'); Merk op dat deze functie inhaakt op de wp_head actie. Om de metabeschrijving in het hoofdelement te schrijven, moeten we dat doen echo de string in plaats van terugkeer de snaar.
Merk nu op dat we in de bovenstaande test gebruiken expectOutputString. Dit is handig wanneer we een functie moeten evalueren die echo's een string (in plaats van komt terug Een touwtje). Sinds de wp_head actie gaat een aanzienlijke hoeveelheid gegevens teruggeven (dat wil zeggen, het hele hoofdelement), we hoeven echt alleen de meta-beschrijving die wordt teruggestuurd te evalueren. En dat is waarom in plaats van bellen do_action ('wp_head'), Ik roep eenvoudig de functie zelf op en evalueer de output tegen wat ik verwacht dat het zal hebben.
Nogmaals, voer PHPUnit uit en je tests zouden allemaal moeten slagen.
Het is duidelijk dat we slechts de oppervlakte hebben bekrast van wat eenheidstesten kunnen doen voor onze thema-ontwikkeling. Er kan nog veel worden getest - we hebben zelfs niet eens gekeken naar het testen van The Loop, verschillende manieren om postformaten te evalueren, of zelfs om opmerkingen te bekijken.
Onthoud dit is een beginnersgids en de drie artikelen bestrijken een heleboel grond.
Hoe dan ook, de principes zijn hetzelfde: het is een kwestie van ervoor zorgen dat je de juiste functie of actie programmatisch inschakelt en de uitvoer ervan evalueert in zowel verwachte als onverwachte gevallen.
Ten slotte vindt u het hele project samen met gedocumenteerde functies in deze GitHub-repository.
Hier is een samenvatting van de bronnen die in dit artikel worden gebruikt:
assertTrueassertFalsewp_script_isdo_actionwp_headexpectOutputString