Share
I de to første artiklene i denne serien tok vi et høyt utseende på hvilken enhetstesting som er og hvordan man bruker den i sammenheng med plugin-utvikling. Selvfølgelig er det mer å WordPress enn å skrive plugins, er det ikke? En betydelig del av en WordPress-utvikler jobb - for noen er det mest betydelig del - er temautvikling.
Så i denne artikkelen skal vi se på hvordan man utvikler testbare temaer. Spesielt skal vi se på hvordan temaer er forskjellige enn plugins, og så skal vi skrive et ekstremt enkelt tema som skal brukes til å demonstrere prinsippene for enhetstesting og som kan brukes i fremtidig utvikling.
Før vi begynner å lage et tema eller gjennomgå en kode, er det viktig å forstå forskjellen i tema og plugin utvikling. For det første kan plugins skrives på to måter:
Begge metodene gjør det samme: det vil si, de bruker en samling funksjoner og filtre for å introdusere ny funksjonalitet til WordPress. Den primære forskjellen er hvordan funksjonene er innkapslet.
Men når det gjelder temautvikling, er det egentlig bare en måte å utvikle et tema på, og det er ved å bruke en samling funksjoner definert i functions.php. Dette presenterer følgende to utfordringer for å skrive enhetstester for temaer:
Fordi gode temaer bruker en samling av filtre og handlinger, skal vi skape et tema som følger disse beste praksisene, og fordi vekten av denne artikkelen ligger i enhetstestingstemaer, vil det bli lagt større vekt på å skrive testene i stedet for skaper et godt utseende, svært funksjonelt tema.
Før koding, la oss initialisere prosjektets katalog. Vi må sette opp skjelettet av temaet, så opprett en ny katalog for temaet i WordPress temakatalog. Mine er kalt Basic-tema. Legg til følgende filer (vi fyller dem ut senere):
La oss gå videre og stub ut stilarket slik at WordPress gjenkjenner temaet og lar oss aktivere det fra Dashboard. For å gjøre det, legg til følgende kode:
/ * Tema Navn: Basic Theme Theme URI: TODO Versjon: 1.0 Beskrivelse: Et grunnleggende tema som brukes til å demonstrere hvordan man skriver enhetstester for temaer. Forfatter: Tom McFarlin Forfatter URI: http://tommcfarlin.com Lisens: GNU General Public License v2.0 Lisens URI: http://www.gnu.org/licenses/gpl-2.0.html * /
For å være komplett, fortsett og legg til å åpne og lukke PHP-koder til begynnelsen og slutten av funksjonsfilen din. Dette vil sikre at vi har grunnlaget lagt når vi begynner å skrive temafunksjoner senere i denne artikkelen.
Og legg til en ny katalog som heter tester. Her må vi legge WordPress-testene.
Tidligere i denne serien ga jeg en kobling til WordPress-tester som ligger på GitHub. Selv om disse testerne er fine å bruke, er de nyeste, automatiske, vedlikeholdte WordPress-testerne plassert i dette Subversion-depotet.
Hvis du er en avansert utvikler, anbefaler jeg at du sjekker ut disse testene. Men hvis du bare har startet med enhets testing - ikke noe problem! Jeg gir all kildekoden - inkludert WordPress-testene - i et GitHub-depot som du kan laste ned, referere til og bruke til egne prosjekter.
Når testene er installert, bør temaets katalog se slik ut:
Fordi PHPUnit må utføres fra kommandolinjen, må du åpne en terminal økt (eller en kommandoprompt), navigere til tester katalog, og du bør kunne kjøre dem ved hjelp av følgende kommando (som et eksempel):
phpunit tester / test_user_capabilities.php
Terminalen din skal da skrive ut noe slikt:
Hodet opp: Hvis du ikke klarer å utføre testene, kan du se tilbake til den første artikkelen i serien for å bekrefte konfigurasjonen. I tillegg kan kjørelengde varierer basert på operativsystem, webserver og lokal maskinkonfigurasjon. Hvis du ender med å gjøre noe annet, vennligst del notatene dine i kommentarene for å hjelpe andre. På dette punktet, la oss fortsette å aktivere temaet i Dashboard. Temaet bør aktiveres (hvis ikke, sørg for at du ikke har noen svarte tegn i malfiler). Hvis du prøver å se temaet, vil det naturligvis vise en hvit skjerm.
Før du skriver noen tester, la oss gå videre og fylle ut våre malfiler med litt innhold akkurat slik vi kan ha noe dukker opp på fronten.
I header.php, legg til følgende kode:
<?php wp_title("); ?> >Dette er toppteksten.
I index.php, legg til følgende kode:
Dette er innholdet.
Og i footer.php, legg til følgende kode:
Dette er bunnteksten.
Enkel, jeg vet, men dette vil gi oss akkurat nok til å jobbe med når vi begynner å skrive tester. Lagre arbeidet ditt, vurder temaet i nettleseren, og du bør se dette:
I din tester katalog, opprett en fil som heter test_basic_theme.php og stub ut filen for å se slik ut:
Accentsconagua
// Inkluder funksjonene for temaet include_once ('... /functions.php'); klasse Test_Basic_Theme utvider WP_UnitTestCase // sluttklasse Ovenfor definerer vi en klasse som vil brukes til å pakke inn alle testehetens tester.
Først, la oss definere Setup metode. De Setup Metode er en funksjon som tilbys av WordPress Test-rammeverket, og vi kan bruke den til å brenne visse funksjoner før testene kjøres. For eksempel, når WordPress-testene kjører, løper de mot standardtemaet - det er tjue elleve. I vårt tilfelle ønsker vi å kjøre testene mot vårt eget tema.
For å gjøre dette må vi fortelle at WordPress faktisk skal bytte temaer før de kjører resten av testene våre. Siden dette må skje før testene kjøres, må det defineres i Setup metode. Gir mening?
Så la oss skrive vår Setup metode:
funksjon setUp () foreldre :: setUp (); switch_theme ('Basic Theme', 'Basic Theme'); // sluttoppsett Igjen, la oss utføre våre tester. Vi kan gjøre dette ved å kjøre samme kommando som vi gjorde da vi først opprettet testen:
phpunit tester / test_basic_theme.php
Tillat at du har gjort alt riktig, bør du faktisk se en feil når testen kjører:
Feilmeldingen er klar, men: "Ingen tester funnet i klassen "Test_Basic_Theme"". Så la oss mildne det og skrive den første testen for temaet. Det kan være noe ekstraordinært enkelt, men husk fra det forrige innlegget at vi ikke vil teste bare Den optimale banen, men feilbanen, også.
Som sådan må vi teste at grunnleggende temaet er aktivt og at tjue elleve ikke er aktivt. For å gjøre dette bruker vi assertTrue-metoden og assertFalse-metoden, og vi gjør det i sammenheng med to funksjoner. Ta en titt på koden under og oppdater testfilen din i henhold til dette:
funksjon testActiveTheme () $ this-> assertTrue ('Basic Theme' == get_current_theme ()); // ende testThemeInitialization function testInactiveTheme () $ this-> assertFalse ('Twenty Eleven' == get_current_theme ()); // end testInactiveTheme Igjen, utfør testene, og du bør se dem runde grønne. Hyggelig, rett?
Dette er en relativt enkel funksjonalitet, så la oss vurdere noen avanserte funksjoner som vårt tema kunne ha.
Ut av boksen inneholder Basic Theme ikke jQuery, så vi skal inkludere det med temaet vårt. Hvis du husker fra de tidligere innleggene, er den riktige enhetstestingsmetoden som følger:
Så, la oss gjøre akkurat dette for jQuery.
Først må vi skrive en test for å avgjøre om jQuery er lastet. Vi bruker WordPress-funksjonen wp_script_is. Siden temaet går gjennom den normale sidens livssyklus i en nettleser, må vi manuelt fortelle WordPress å laste jQuery ved å bruke do_action-funksjonen.
funksjon testjQueryIsLoaded () $ this-> assertFalse (wp_script_is ('jquery')); do_action ('wp_enqueue_scripts'); $ this-> assertTrue (wp_script_is ('jquery')); // end testjQueryIsLoaded Før vi går videre, er det noe viktig å merke seg her: Jeg liker ikke å plassere flere påstander i en enkelt funksjon fordi jeg tror at hver funksjon skal tjene til å teste et enkelt formål; Det er imidlertid unntak. Her må vi sørge for at jQuery er ikke lastet før du ringer do_action.
Uansett, kjør testen og det vil mislykkes. Så vi må legge til koden til functions.php Det vil sørge for at jQuery legges til vårt tema. For å gjøre det, ta med følgende funksjon i funksjonsfilen din:
fungere basic_add_jquery () wp_enqueue_script ('jquery'); // end basic_remove_jquery add_action ('wp_enqueue_scripts', 'basic_add_jquery'); Endelig kjør testen og den skal være grønn. Enkelt nok, er det ikke?
La oss si at vi vil inkludere en standard meta beskrivelse på hjemmesiden. I det enkleste tilfellet vil det ikke være noe mer enn bloggens beskrivelse. Så, i følge med vår metodikk som er skissert over, la oss introdusere en funksjon for å teste at meta beskrivelsestrengen som er lagt til hodeelementet, samsvarer med det vi forventer:
funksjonstestBasicMetaDescription () $ meta_description = ''; $ this-> expectOutputString ($ meta_description, basic_meta_description ()); // end testBasicMetaDescription
Kjør det - det vil mislykkes. Merk at jeg ikke bruker standarden assertTrue, assertFalse funksjoner - det vil bli flere detaljer om dette på et øyeblikk. La oss nå introdusere følgende funksjon i functions.php:
funksjon basic_meta_description () echo ''; // end basic_meta_description add_action ('wp_head', 'basic_meta_description'); Legg merke til at denne funksjonen hooks inn i wp_head handling. For å kunne skrive metabeskrivelsen ut i hovedenheten må vi ekko strengen i stedet for komme tilbake strengen.
Vær oppmerksom på at i testen ovenfor bruker vi expectOutputString. Dette er nyttig når vi må evaluere en funksjon som ekko en streng (heller enn avkastning en streng). Siden wp_head Tiltaket kommer til å returnere en betydelig mengde data (det vil si hele hovedenheten), vi trenger egentlig bare å evaluere metabeskrivelsen som returneres. Og det er derfor heller enn å ringe do_action ('wp_head'), Jeg ringer ganske enkelt selve funksjonen og evaluerer produksjonen mot det jeg forventer at den skal ha.
Igjen, kjør PHPUnit og testene dine skal alle bestå.
Det er klart at vi bare har kløftet overflaten av hvilken enhetstesting som kan gjøres for vår temautvikling. Det er fortsatt mye som kan testes - vi har ikke engang tatt en titt på å teste The Loop, forskjellige måter å evaluere innleggformater på, eller til og med å undersøke kommentarer.
Husk dette er en nybegynnerveiledning og de tre artiklene dekker mye bakken.
Uansett er prinsippene det samme: Det er et spørsmål om å sørge for at du programmatisk brenner den aktuelle funksjonen eller handlingen, og evaluerer dens produksjon i både forventede og uventede tilfeller.
Til slutt finner du hele prosjektet sammen med dokumenterte funksjoner i dette GitHub-depotet.
Her er en oppsummering av ressursene som brukes i denne artikkelen:
assertTrueassertFalsewp_script_isdo_actionwp_headexpectOutputString