Share
I den første delen av denne serien tok vi et høyt utseende på testmetoder og ga noen tilfeller om hvorfor det er gunstig for oss å begynne å gjøre i våre WordPress-prosjekter. Vi tok også tid til å konfigurere PHPUnit og WordPress Testene for å begynne å bygge vårt første testbare plugin.
I denne siste artikkelen skal vi definere en metode for enhetstesting, begynne å inkorporere den i arbeidet vårt, og gå bort med en fullt funksjonell (om enn enkel) plugin som også har et lite sett med tester for å sikre at det fungerer akkurat som forventet.
Når det gjelder testing, er det generelt to måter å gjøre det på:
Etter min erfaring er den første tilnærmingen alltid bedre. Gitt dette er praktisk talt umulig å gjøre innenfor rammen av en søknad som allerede eksisterer, men hvis du starter fra grunnen - som vi er - er det en bedre tilnærming, og her er hvorfor: Når du har skrevet en søknad, har du vet hvordan det fungerer. Som sådan kan det være ekstremt vanskelig å skrive tester som strekker applikasjonen når du ikkje vet hvordan den skal fungere.
Til det formål finner jeg det bedre å skrive testene først. På denne måten inkluderer testene ikke bare måten programmet er på ment å jobbe, men det blir også en form for dokumentasjon som viser hvilken funksjonalitet som er ment og vil til slutt gi en feil når funksjonaliteten ikke fungerer som den skal.
Med det i tankene skal vi bygge med denne enkle metoden:
Til slutt, som en oppdatering, kommer pluginet vårt til å gi en spesialisert velkomstmelding til den besøkende basert på om de har klikket til nettstedet fra enten Google eller Twitter. Vi skriver også dette på en slik måte at det blir enklere å utvide med tilleggstjenester, hvis du vil gjøre det i fremtiden.
På dette tidspunktet er det på tide å begynne å skrive noen kode; Men i motsetning til de fleste prosjekter kommer vi ikke til å hoppe inn i WordPress-spesifikke koden ennå. I stedet skal vi studere vår enhetstestklasse. Hvis du har strukturert plugin-katalogen din basert på hva vi delte i det første innlegget eller hvordan vi har konfigurert det på GitHub, bør du ha en hello_reader_tests.php filen ligger i din prøver / wordpress-tester katalogen. Du trenger selvfølgelig ikke å følge denne organisasjonen, men det vil hjelpe når vi utvikler seg gjennom prosjektet.
La oss stikke ut enhetstestklassen:
Accentsconagua
require_once ('... / ... /plugin.php'); klasse Hello_Reader_Tests utvider WP_UnitTestCase // sluttklasse Nå, prøv å kjøre testen ved hjelp av terminalen ved hjelp av PHP-enheten. Forutsatt at du kjører PHP-enhet fra din lokale MAMP-installasjon, bør du kunne skrive inn:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit ./hello_reader_tests.php
På dette punktet bør du se en feil:
Det er bra! Det betyr at PHPUnit er installert og kjører, og at ditt WordPress Testing-rammeverk er klart å gå. Testen mislyktes bare fordi vi ikke har skrevet noen tester. La oss begynne å gjøre det.
Først, la oss skrive en test for å sikre at pluginet vårt er initialisert, instantiated og klar for testing. Husk tidligere i den første artikkelen at vi lagret en referanse til forekomsten av Hello Reader i PHP $ Globals array. Slik får vi tilgang til forekomsten ved hjelp av testrammen. Så la oss oppdatere vår enhetstest for å se slik ut:
Vær oppmerksom på at jeg, for pluts skyld, vil forlate kodekommentarer, men det fullt kommentert plugin og tester vil være tilgjengelige på GitHub.
require_once ('... / ... /plugin.php'); klasse Hello_Reader_Tests utvider WP_UnitTestCase private $ plugin; funksjon setUp () foreldre :: setUp (); $ this-> plugin = $ GLOBALS ['hei-leser']; // ende oppsettfunksjonstestPluginInitialisering () $ this-> assertFalse (null == $ this-> plugin); // end testPluginInitialization // end class Ovenfor har vi satt opp en referanse til forekomsten av plugin slik at vi kan få tilgang til den gjennom våre enhetstester. Vi bruker Setup metode for å hente referansen til plugin fra $ Globals. Vær imidlertid oppmerksom på at vi har introdusert en annen funksjon som heter testPluginInitialization. Denne funksjonen verifiserer at referansen vi har satt opp i Setup Metoden er ikke null.
Hvis du prøver testene, bør du nå få beståttest, og terminalen din skal se slik ut:
Det er en viktig takeaway her: Merk at den eneste funksjonen vi har gitt ovenfor, har et klart formål: å kontrollere at pluginet er riktig initialisert. Funksjonsnavnet er klart og inneholder en enkelt påstandserklæring. Dette er en fin måte å modellere våre resterende tester, først og fremst fordi det gjør det enkelt å finne feil når de vises. Tenk på det på denne måten: Hvis du inkluderer en rekke forskjellige påstandserklæringer i en enkelt funksjon, vil det være vanskelig å fastslå hvilken påstandserklæring som feiler.
Nå som vi har blitt introdusert til hvordan du skriver enhetstester, kjører enhetstester, og evaluerer hvordan de går, eller hvordan de feiler, la oss begynne å implementere funksjonalitet for plugin. Først må vi sette opp et filter for innholdet siden vi skal legge til tekst i begynnelsen av innholdet. I følge med metodikken som vi definerte tidligere i denne artikkelen, la oss først skrive vår test.
Denne spesielle testen skal se for å se om vi har lagt til et bestemt sett med tekst til den første delen av innlegget:
funksjonstestAddWelcomeMessage () $ this-> assertEquals ('TEST CONTENT', $ this-> plugin-> add_welcome_message ('Dette er eksempel etter innhold. Dette simulerer at WordPress vil returnere når du ser et blogginnlegg.'), 'add_welcome_message ) legger velkommen melding til innleggets innhold. '); // end testAddWelcomeMessage Hvis du kjører testen nøyaktig slik den er, vil den ikke engang feile - i stedet vil PHPUnit returnere en dødelig feil fordi metoden ikke er definert i plugin. Så la oss legge til det nå. Oppdater plugin for å se slik ut:
klasse Hello_Reader funksjon __construct () add_filter ('the_content', array (& $ this, 'add_welcome_message')); // end constructor public function add_welcome_message ($ innhold) // end add_welcome_message // sluttklasse Prøv nå å kjøre testen. Testen vil ikke bombe, men du bør faktisk se en feil sammen med en klar melding om hvorfor testen mislyktes:
1) Hello_Reader_Tests :: testAddWelcomeMessage add_welcome_message () legger velkomstmelding til innleggets innhold. Kunne ikke hevde at null-kamper forventet 'TEST CONTENT'
Så, i tråd med vår metodikk, vil vi gjøre denne testen bestått. For å gjøre det, må vi sørge for at innleggets innhold inneholder tekststrengen - i dette tilfellet "TEST INNHOLD', for å få det til å passere. Så la oss prøve dette. Oppdater den tilsvarende funksjonen i plugin for å legge til strengen før innholdet:
offentlig funksjon add_welcome_message ($ content) return 'TEST CONTENT'. $ Innhold; // end add_welcome_message
Og igjen, vi gjenoppretter testen bare for å se at den mislykkes. Hvis du ser vår test, er dette fordi det ser ut til å se innholdet vårt er lik den "TEST INNHOLD'streng. I stedet må vi sørge for at strengen starter på innholdet. Dette betyr at vi må oppdatere testen vår. Heldigvis har PHPUnit en assertContains-funksjon. Så la oss oppdatere koden vår for å bruke den:
funksjonstestAddWelcomeMessage () $ this-> assertContains ('TEST CONTENT', $ this-> plugin-> add_welcome_message ('Dette er eksempel etter innhold. Dette simulerer at WordPress vil returnere når du ser et blogginnlegg.'), 'add_welcome_message ) legger velkommen melding til innleggets innhold. '); // end testAddWelcomeMessage Igjen, prøv testen igjen, og du bør se at testen nå går. Rått! Nå må vi skrive tilpassede meldinger for personer som kommer fra Twitter og folk som kommer fra Google.
Det finnes en rekke forskjellige måter vi kan sjekke for å se hvordan en bruker har kommet til en bestemt side. Noen ganger kan vi sjekke verdiene i $ _GET array, noen ganger kan vi forhøre $ _SERVER array, eller noen ganger kan vi sjekke en brukers økt. I dette eksemplet skal vi lete etter 'twitter.com' som finnes i $ _SERVER [ 'HTTP_REQUEST']. Jeg sier dette bare slik at dere kan følge med det vi gjør i koden.
Så generelt sett add_welcome_message bør sjekke for å se om forespørselen er kommet fra Twitter og skreddersy meldingen på riktig måte. Siden vi er i ferd med å teste hver funksjonalitet, kan vi skrive en funksjon som kan vurdere om forespørselen kommer fra Twitter. Så la oss skrive en ny test:
I plugin:
offentlig funksjon is_from_twitter () // end is_from_twitter
I testen:
funksjon testIsComingFromTwitter () $ _SERVER ['HTTP_REFERER'] = 'http://twitter.com'; $ this-> assertTrue ($ this-> plugin-> is_from_twitter (), 'is_from_twitter () vil returnere sann når henvisningswebområdet er Twitter.'); // ende testIsComingFromTwitter
Vi er åpenbart spoofing the HTTP_REFERER verdi, men det er greit for dette eksemplet. Poenget er fortsatt: Kjør testen, det vil mislykkes, og så må vi implementere funksjonen i pluginet for å få det til å passere:
offentlig funksjon is_from_twitter () return strpos ($ _SERVER ['HTTP_REFERER'], 'twitter.com')> 0; // end er_from_twitter
Forny testen bør nå resultere i en bestått test. Men vent - vi må være ferdige. La oss sørge for at vi kjører en test for å bekrefte at denne funksjonen mislykkes når henvisningen er ikke fra Twitter.
funksjon testIsNotComingFromTwitter () // Spoofing HTTP_REFERER med henblikk på denne testen og følgesvenn bloggen innlegg $ _SERVER ['HTTP_REFERER'] = 'http://facebook.com'; $ this-> assertFalse ($ this-> plugin-> is_from_twitter (), 'is_from_twitter () vil returnere sann når henvisningswebområdet er Twitter.'); // ende testIsNotComingFromTwitter
Legg merke til at vi har oppdatert HTTP_REFERER og vi har endret seg assertTrue til assertFalse. Tillate alt annet er riktig, kjøre testene og de skal passere.
Å gi en tilpasset melding til Google vil kreve det samme som vi gjorde for Twitter, det vil si, forfalske HTTP_REFERER og returner sann eller falsk for hjelpefunksjonen. Så, for å unngå å lyde overflødig, holder jeg denne delen så kortfattet som mulig. De samme trinnene må følges som for Twitter.
Først stikker vi ut hjelperfunksjonen i plugin:
offentlig funksjon is_from_google () // end is_from_google
Så stubber vi ut testen:
funksjon testIsComingFromGoogle () $ _SERVER ['HTTP_REFERER'] = 'http://google.com'; $ this-> assertTrue ($ this-> plugin-> is_from_google (), 'is_from_google () vil returnere sant når henvisningswebområdet er Google.'); // end testIsComingFromGoogle
Kjører testen som det er akkurat nå, vil føre til en feil. Så, la oss implementere is_from_google () funksjon:
offentlig funksjon is_from_google () return strpos ($ _SERVER ['HTTP_REFERER'], 'google.com')> 0; // end er_from_twitter
Og nå skal testen passere. Men igjen må vi være komplette, så la oss skrive feilstesten for å anta at funksjonen ikke kommer tilbake sant når brukere kommer fra et annet sted:
funksjon testIsNotComingFromGoogle () // Spoofing HTTP_REFERER med henblikk på denne testen og følgesvenn bloggen innlegg $ _SERVER ['HTTP_REFERER'] = 'http://facebook.com'; $ this-> assertFalse ($ this-> plugin-> is_from_google (), 'is_from_google () vil returnere sant når henvisningswebområdet er Google.'); // end testIsNotComingFromGoogle
Endelig kjør testene dine. Tillat alt annet er riktig, du bør ha seks beståttester.
På dette tidspunktet har vi alt vi trenger for å begynne å vise tilpassede velkomstmeldinger til brukerne våre. Det eneste er at vi må refactor vår første test som sjekker for "TEST CONTENT." Nå må vi introdusere tester for følgende tilfeller:
Så la oss fjerne testen vi opprettet tidligere testAddWelcomeMessage i stedet for å legge til tre nye tester.
Først legger vi til en test som sjekker Twitter-velkomstmeldingen.
I plugin reduserer vi add_welcome_message til dette:
offentlig funksjon add_welcome_message ($ content) return $ content; // end add_welcome_message
Og vi legger til Twitter-testen, først:
funksjonstestDisplayTwitterWelcome () // Spoof HTTP_REFERER for Twitter $ _SERVER ['HTTP_REFERER'] = 'http://twitter.com'; $ this-> assertContains ('Velkommen fra Twitter!', $ this-> plugin-> add_welcome_message ('Dette er eksempel etter innhold. Dette simulerer at WordPress vil returnere når du ser et blogginnlegg.'), 'add_welcome_message melding til innleggets innhold. '); // end testDisplayTwitterWelcome På dette punktet er dette gammel hatt, ikke sant? Kjør det, testen vil mislykkes. Gjennomfør add_welcome_message å se slik ut:
offentlig funksjon add_welcome_message ($ innhold) if ($ this-> is_from_twitter ()) $ content = 'Velkommen fra Twitter!' . $ Innhold; // slutt hvis retur $ innhold; // end add_welcome_message
Kjør det igjen, og det vil passere. Neste opp er Google-testen:
funksjonstestDisplayGoogleWelcome () // Spoof HTTP_REFERER for Google $ _SERVER ['HTTP_REFERER'] = 'http://google.com'; $ this-> assertContains ('Velkommen fra Google!', $ this-> plugin-> add_welcome_message ('Dette er eksempel etter innhold. Dette simulerer at WordPress vil returnere når du ser et blogginnlegg.'), 'add_welcome_message melding til innleggets innhold. '); // end testDisplayGoogleWelcome Kjør testen, mislykkes, oppdater deretter add_welcome_message i plugin for å inneholde en sjekk ved hjelp av hjelperfunksjonen vi skrev tidligere:
offentlig funksjon add_welcome_message ($ innhold) if ($ this-> is_from_twitter ()) $ content = 'Velkommen fra Twitter!' . $ Innhold; annet hvis ($ this-> is_from_google ()) $ content = 'Velkommen fra Google!' . $ Innhold; // slutt hvis retur $ innhold; // end add_welcome_message
På dette punktet bør du ha et fullt funksjonelt plugin som har syv bestått enhetstester!
Som du kan se, innfører enhetstesting et ekstra utviklingsnivå, men kan lønne seg betydelig i vedlikeholdsbar, velorganisert og testbar kode. Etter hvert som søknaden din vokser, fortsetter løpende tester for å verifisere at prosjektene fungerer som forventet, kan gi deg hjerte. Selvfølgelig er dette bare et lite eksempel på hvordan enhetstesting fungerer. Bruk av disse metodene kan lønne seg i mye større og / eller kompliserte prosjekter.
Endelig kan du finne dette pluginet, WordPress-testene, og Hello Reader-enhetstesterne fullt ut kommentert GitHub.
