Så langt har vi gjort lite mer enn å introdusere deg for ideen om å bygge tester for WordPress-pluginene dine og snakke om en haug med de ekstra begrepene du trenger å forstå for å dykke dypere inn i å teste koden din. I dag skal vi gjøre det praktisk ved å ta en av mine gratis plugins og legge til noen enhetstester for å vise deg hvordan du setter det sammen.
Du kan finne plugin på Github eller WordPress.org. Akkurat som mitt forrige innlegg, antar jeg at du har WP CLI installert og kan sette opp grunnleggende tester. Hvis du ikke kan sjekke ut innlegget mitt som introduserer deg for enhetstesting i WordPress.
I motsetning til forrige gang trenger vi bare å stillasere testene slik at vi kan starte med følgende kommando i WordPress-installasjonen vår.
wp scaffold plugin-tester wptt-ics-feeds
La oss nå begynne å skrive noen tester.
Test brukerlenker
Det første jeg vil teste er å forsikre meg om at koblingene en bruker ser i profilen sin med kalenderfeeds er riktige. Spesielt skal vi se på get_subscribe_link funksjon.
Du kan se de fullførte testene for denne delen her.
La oss starte med å kopiere standard prøvetestfilen og gi den nytt navn til test-feed-links.php. Jeg liker alltid å lage forskjellige filer for områdene av pluginene jeg skriver tester for, selv om det betyr at jeg har mange filer å forholde meg til. Det er mye enklere å holde orden med tydelig merkede filer.
Denne plugin-en er litt eldre og instansierer en global variabel når den starter opp. Dette lar oss kalle det globalt når vi er i oppsettfunksjonen vår, slik at vi har tilgang til plugin-koden. Vi må også bruke WordPress Factory til å sette opp en ny bruker slik at vi kan teste koblingene som er gitt med den brukeren. Det betyr at våre oppsett- og rivefunksjoner skal se slik ut.
offentlig funksjonsoppsett(){
overordnet::oppsett();
// får plugin global
$this->plugin = $GLOBALS[‘wptt_ics_feeds’];
// lage en falsk bruker
$this->editor = new WP_User( $this->factory->user->create( array( ‘role’ => ‘editor’ ) ) );
}
offentlig funksjon tearDown(){
forelder::tearDown();
wp_delete_user( $this->editor->ID, true );
}
Nå kan vi begynne å skrive en test for feedlenkene våre. Vi skal skrive to forskjellige tester for å teste begge situasjonene som lenkefunksjonen kan finne seg i. Først tester vi get_subscribe_link() uten noen argumenter.
/**
* Tester basefeedkobling uten forfatter
*/
offentlig funksjon test_base_feed_link(){
$feed_link = $this->plugin->get_subscribe_link();
$complete_link = site_url() . ‘/?feed=wptticsfeeds’;
$this->assertEquals( $feed_link, $complete_link, ‘Feedlenkene er ikke like’ );
}
Det første koden ovenfor gjør er å få tilgang til plugin-forekomsten vår som definert i setUp-funksjonen og kalle opp get_subscribe_link()-funksjonen. Deretter hardkoder jeg den forventede utgangen av funksjonen slik at jeg har noe å sammenligne med. Til slutt bruker vi assertEquals å sammenligne de to verdiene.
Når det er gjort, kan jeg gå tilbake til terminalen og kjøre testene med phpunit-kommandoen. Hvis testene mine består, vil jeg se noe som utgangen nedenfor. Hvis de ikke består, får jeg en stor rød advarsel i stedet for en grønn linje, noe som betyr at jeg må finne ut hvorfor de ikke består og fikse testene.
I dette tilfellet besto testene våre, og vi kan gå videre til å teste utdataene fra lenkefunksjonen vår hvis vi besetter et forfatternavn. Du kan se denne testen nedenfor.
/**
* Tester feedlink med forfatter
*/
offentlig funksjon test_author_feed_link(){
$feed_link = $this->plugin->get_subscribe_link( array( ‘author’ => $this->editor->ID ) );
$complete_link = esc_url( site_url() . ‘/?feed=wptticsfeeds&wpttauthor=”. $this->editor->user_login );
$this->assertEquals( $feed_link, $complete_link, “Feedlenkene til forfatteren er ikke like” );
}
Her gjør vi nesten det samme som vi gjorde da vi testet linken vår tidligere. Endringen er at vi sender inn brukeren vi opprettet med oppsettfunksjonen vår og tester deretter for å sikre at denne linken kommer ut som forventet med assertEquals.
La oss nå gå videre til å teste det tilpassede filteret inne i plugin-en.
Teste et WordPress-filter med PHPUnit
Jeg har hatt noen tvister med andre utviklere om testing av filtre tidligere. Noen gidder ikke å teste de interne plugin-filtrene sine, men jeg synes du bør teste disse filtrene. Noen ganger endres filternavn og du glemmer dette, så ikke dokumenter det hvor som helst eller se etter bruk av filteret. Å skrive en enkel test for filteret ditt vil fremheve dette fordi når du endrer filternavnet vil det oppstå en testfeil.
For denne testen legger vi til en ny fil i testmappen vår kalt test-filters.php. Jeg skal bruke denne filen til å teste alle fremtidige filtre som må testes i plugin. Denne gangen trenger oppsettfunksjonen vår bare å instansiere en forekomst av plugin-modulen vår, og tearDown-funksjonen vår trenger ikke å gjøre noe. Se koden nedenfor.
offentlig funksjonsoppsett(){
overordnet::oppsett();
// får plugin global
$this->plugin = $GLOBALS[‘wptt_ics_feeds’];
}
offentlig funksjon tearDown(){
forelder::tearDown();
}
Deretter må vi skrive testen for filteret vårt som du kan se nedenfor.
/**
* Tester at innlegget hvor tid kan endres med et filter
*/
public function test_posts_where_filter(){
add_filter( ‘wptt_ics_feeds_how_old’, array( $this, ‘new_where’ ), 10, 2 );
$output = $this->plugin->two_months( ” );
$date = date(‘Ym-d’, strtotime( $this->new_where()) );
$this->assertStringContainsString( $date, $output, ‘Datofilteret fungerte ikke’ );
}
offentlig funksjon new_where(){
returner ‘-1 uke’;
}
Det første vi gjør er å kalle filteret vårt og deretter sende det vår new_where-funksjon. Jeg liker alltid å skrive en egen funksjon for filtertester fordi jeg har endt opp med å bruke dem i flere tester nok til at jeg føler at dette sparer arbeid senere. Vår new_where-funksjon vil sende strengen -1 uke til filteret vårt.
Deretter kaller vi vår two_months() funksjon inne i plugin. Da bruker vi en standard PHP Dato funksjon for å få formatet vi forventer for datoen. Siden jeg er mest opptatt av at datoen blir analysert riktig i plugin-en jeg bruker assertStringContainsString for å sjekke om utdataene til funksjonen two_months inneholder samme datostreng som $date-variabelen.
Igjen, hvis testene dine består, bør alt være grønt. Hvis de mislykkes, får du en stor rød advarsel i stedet for den hyggelige grønne linjen.
Hvorfor tester vi ikke ICS-feedutgangen
Merk at jeg ikke testet den endelige utgangen av ICS-feeden vår. Selv om dette er mulig, har den en haug med bevegelige deler som kan svikte og ikke har noe med koden min å gjøre. Jeg kan sende ICS-feeden til en online validator og deretter motta JSON-svaret og analysere det for å sjekke om det er gyldig.
Hvis HTTP-forespørselen mislykkes, mislykkes testen min. Hvis den elektroniske valideringstjenesten slår seg av, mislykkes testen min. Det er en haug med andre scenarier som også kan føre til at testen min mislykkes uten grunn, det er min feil. På grunn av dette valgte jeg å ikke teste den endelige feeden programmatisk og regnet med at jeg kunne teste den ved å abonnere på en feed i kalenderen min og se at innleggene mine faktisk var på kalenderen som forventet.
Dette er ikke enhetstesting
Jeg er sikker på at noen av dere ser på dette og sier at jeg ikke skriver enhetstester, og du vil ha rett. Jeg skriver integrasjonstester fordi koden min integreres med WordPress for at testene skal fungere. Ja, du kan bruke WP_Mock å falske WordPress for å skrive sanne enhetstester, men mesteparten av tiden bryr jeg meg om at koden min fungerer med WordPress.
I dag har vi sett på å legge til noen tester til en eksisterende WordPress-plugin som et praktisk eksempel på hvordan testing kan fungere for prosjektene dine. For å fortsette å lære, sjekk ut forretningssaken for å legge til testing i prosessen din som bedriftseier. Det kan være vanskelig å se forbi forhåndsutgiftene siden utviklingen vil ta lengre tid, men det lønner seg.
