Share
Avhengig av bakgrunnen, kan du eller kanskje ikke ha hørt om enhetstesting, testdrevet utvikling, oppførselstyrt utvikling eller en annen type testmetode. Ofte brukes disse metodene i sammenheng med større programvare systemer eller applikasjoner og mindre i sammenheng med WordPress-baserte prosjekter (selv om det er blir bedre!)
Helt ærlig er utviklingssamfunnet litt delt på automatisert programvare testing - du har noen som tror at du skal ha tester for 100% av hele koden din, noen tror at 80% er tilstrekkelig, noen 50%, og noen er fornøyd med 20% eller så. Uansett hva som er tilfelle, handler denne artikkelen ikke om å argumentere for et nivå for tester du burde ha i prosjektet, eller tar det stilling til generell programvare testing.
I stedet skal vi ta en titt på hva som kreves for å komme seg opp med enhet som tester dine WordPress-utviklingsprosjekter. Vi kommer til å nærme seg denne serien fra et absolutt nybegynners perspektiv, slik at vi kan forstå fordelene ved enhetstesting og hvordan vi konfigurerer miljøet vårt for å støtte enhetstestingsbiblioteker, slik at vi kan begynne å gjøre dette i vårt fremtidige arbeid. Til slutt vil alt dette gjøres ved å bygge og teste et enkelt, testbart plugin fra grunnen.
Før vi begynner å sette opp miljøet vårt og skrive noen kode, la oss definere nøyaktig hvilken enhetstesting, hvorfor det er verdt å gjøre, og hvordan komme i gang med å inkorporere det i våre prosjekter.
På et høyt nivå refererer enhetstesting til bruken av å teste visse funksjoner og områder - eller enheter - av koden vår. Dette gir oss muligheten til å verifisere at våre funksjoner fungerer som forventet. Det vil si at for en hvilken som helst funksjon og gitt et sett av innganger, kan vi avgjøre om funksjonen returnerer de riktige verdiene og vil håndtere feil i løpet av utførelsen dersom ugyldig inngang blir gitt.
Til slutt hjelper dette oss med å identifisere feil i våre algoritmer og / eller logikk for å forbedre kvaliteten på koden som komponerer en bestemt funksjon. Når du begynner å skrive flere og flere tester, oppretter du en serie tester som du kan kjøre når som helst under utviklingen, for kontinuerlig å verifisere kvaliteten på arbeidet ditt.
En annen fordel å nærme seg utvikling fra et enhetstestperspektiv er at du sannsynligvis vil skrive kode som er lett å teste. Siden enhetstesting krever at koden din enkelt kan testes, betyr det at koden din må støtte denne typen evaluering. Som sådan er det mer sannsynlig at du har et høyere antall mindre, mer fokuserte funksjoner som gir en enkelt operasjon på et sett med data i stedet for store funksjoner som utfører en rekke forskjellige operasjoner.
En tredje fordel for å skrive faste enhetstester og velprøvd kode er at du kan forhindre fremtidige endringer i å bryte funksjonaliteten. Siden du tester koden din når du introduserer funksjonaliteten din, skal du begynne å utvikle en serie testfaser som kan kjøres hver gang du jobber med logikken din. Når en feil oppstår, vet du at du har noe å ta opp.
Selvfølgelig kommer dette på bekostning av å investere tid til å skrive en serie tester tidlig i utviklingen, men når prosjektet vokser kan du bare kjøre testene du har utviklet for å sikre at eksisterende funksjonalitet ikke blir ødelagt når ny funksjonalitet er introdusert.
En av de beste måtene å komme i gang med enhetstesting er å gjøre det i sammenheng med en praktisk applikasjon. Gjennom denne todelte serien skal vi bygge en enkel plugin og skrive tester for å dekke alle funksjonalitetene.
Først, la oss planlegge prosjektet: Vi skal skrive en liten plugin som legger til en enkel melding øverst i et enkelt innlegg som ønsker brukeren velkommen basert på hvordan de har funnet et bestemt blogginnlegg. Ideen ligner veldig godt på Welcome Reader, men det vil ikke inneholde nær så mye funksjonalitet - vi bygger bare en demonstrasjon for å lære inn og ut av testing.
Uansett, her er hvordan pluginet vil fungere:
Rett nok, ikke sant? Dette vil også gi grunnlag for å legge til egendefinerte meldinger for andre tjenester og videre utvide enhetens testingskapasiteter dersom du vil gjøre det.
For å kunne teste koden vår, trenger vi et tredjepartsbibliotek som vi inkluderer i vårt prosjekt som faktisk skal utføre testene vi skriver. I denne serien skal vi bruke PHPUnit. Du kan ta en kopi av det her.
Deretter må vi forberede vårt utviklingsmiljø, stubbe ut pluginet vårt og inkludere de nødvendige bibliotekene for å teste vår kode. Denne artikkelen antar at du allerede har en funksjonell WordPress-installasjon oppe og går.
Så, først, la oss forberede plugin katalogen:
Her er skjelettet for pluginet som vi skal skape:
/ * Plugin Name: Hei Reader Plugin URI: http://github.com/tommcfarlin/Hello-Reader Beskrivelse: En enkel plugin brukes til å demonstrere enhetstesting i sammenheng med WordPress. Versjon: 1.0 Forfatter: Tom McFarlin Forfatter URI: http://tom.mcfarl.in Forfatter Email: [email protected] Lisens: Copyright 2012 Tom McFarlin ([email protected]) Dette programmet er gratis programvare; Du kan omfordele den og / eller endre den under vilkårene i GNU General Public License, versjon 2, som publisert av Free Software Foundation. Dette programmet distribueres i håp om at det vil være nyttig, men UTEN NOGEN GARANTI; uten selv den underforståtte garantien om SALGBARHET eller EGNETHET TIL ET BESTEMT FORMÅL. Se GNU General Public License for mer informasjon. Du burde ha mottatt en kopi av GNU General Public License sammen med dette programmet; Hvis ikke, skriv til Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * / // Opprett bare en forekomst av pluginet hvis den ikke allerede eksisterer i GLOBALS hvis (! array_key_exists ('hello-reader', $ GLOBALS)) class Hello_Reader function __construct () // endconstructor // end class // Lagre en referanse til pluginet i GLOBALS slik at enhetstesterne kan få tilgang til det $ GLOBALS ['hello-reader'] = ny Hello_Reader (); // slutt om
På dette tidspunktet bør du kunne navigere til "Plugins" i WordPress Dashboard og se en oppføring for "Hello Reader." Selvfølgelig gjør dette pluginet ikke noe enda ennå - vi vil fokusere på det (samt hvorfor vi utnytter den $ Globals array) i neste artikkel.
Til slutt, la oss sette opp testrammen slik at vi kan skrive våre tester. Først må vi installere PHPUnit og da må vi installere WordPress-testene.
Merk: Det neste avsnittet vil kreve noe arbeid med terminalen og vil sannsynligvis kreve at du utsteder noen få kommandoer for å opprette symbolske lenker. Jeg har forsøkt å gjøre dette så enkelt og enkelt som mulig, men hvert operativsystem og konfigurasjon vil være annerledes. Vennligst følg nøye og jeg inviterer deg til å dele instruksjonene for operativsystemene dine i kommentarene.
PHPUnit er en enhetstestrammepakke spesielt for PHP. WordPress-testene og rammene som vi skal bruke for å skrive våre WordPress-tester, er avhengige av dette. Dessverre varierer installasjonen basert på plattformen din. Jeg kjører for øyeblikket Mac OS X Lion med MAMP Pro og PHP 5.3.6. Hvis du kjører en annen plattform, må du huske å referere til dokumentasjonen og / eller gjerne dele trinnene i kommentarene.
Først åpne en terminal og oppdater pære (dette er anlegget som vi skal bruke for å installere PHPUnit):
$ cd /Applications/MAMP/bin/php/php5.3.6/bin$ sudo. / pear oppgraderingspære
Deretter instruerer Pear å bruke lagringssteder som vi skal spesifisere i terminal:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear config-sett auto_discover 1
Deretter installerer du Pear ved å utstede følgende kommando:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear installere pear.phpunit.de/PHPUnit
Dette vil installere PHPUnit i sammenheng med MAMP-installasjonen. For å teste det ut, kjør følgende kommando i terminalsesjonen din:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit --versjon
Deretter skal følgende melding vises:
PHPUnit 3.6.11 av Sebastian Bergmann.
Merk: Hvis du får en terminalfeil som nevner "unserialize ()", så er det en uoverensstemmelse mellom pærekonfigurasjonen og din versjon av pære. For å løse problemet må du utføre følgende kommando (dette renker bare filen hvis du vil gjenopprette den senere):
$ /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf/Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.old
Nå som vi har PHPUnit installert og fungerer, er det på tide å sette opp WordPress Testing Framework. Du kan ta tak i pakken fra GitHub. Hvis du er komfortabel kloning av depotet, så vær så snill å gjøre det; ellers bare laste ned et arkiv av prosjektet og trekk det inn i test katalog som vi opprettet tidligere i denne artikkelen.
Før vi kjører testene, må vi opprette en config-fil for å kjøre WordPress-tester. Dette er akkurat som å redigere wp-config.php filen med et nytt WordPress-installasjon, men vi gjør det for en testdatabase i stedet. Nedenfor har jeg limt inn konfigurasjonsfilen min og lagt til kommentarer. Jeg vil være sikker på å forplikte dette til GitHub-depotet i denne artikkelen også.
Accentsconagua
/ * Sti til WordPress-kodebase i forhold til plasseringen av disse testene. Siden de er inkludert i vårt plugin, refererer vi til noen få kataloger over. * / define ('ABSPATH', '... / ... / ... / ... / ... /'); / * Navnet på databasen for å kjøre testene. Pass på at dette er en database bare for testing, da den er opprettet og søppel under testene. * / define ('DB_NAME', 'throwaway'); / * De vanlige legitimasjonene for en lokal database. * / define ('DB_USER', 'root'); define ('DB_PASSWORD', '); define (' DB_HOST ',' localhost '); definer (' DB_CHARSET ',' utf8 '); definer (' DB_COLLATE ','); definere ('WPL_DISPLAY', sant); definer ('WP_TESTS_DOMAIN', 'localhost'); definer ('WP_TESTS_EMAIL','[email protected] Definer ('WP_TESTS_NETWORK_TITLE', 'Test Network'); definer ('WP_TESTS_SUBDOMAIN_INSTALL', definer ('WP_TESTS_TITLE', 'Test Blog'); / * Ikke bekymret for å teste nettverk eller underdomener. false); $ base = '/'; / * Cron prøver å lage en HTTP-forespørsel til bloggen, som alltid mislykkes, fordi testene bare kjøres i CLI-modus * / define ('DISABLE_WP_CRON', true); / * Også ikke (WP_ALLOW_MULTISITE) define ('WP_TESTS_BLOGS', 'første, andre, tredje, fjerde'); Hvis (WP_ALLOW_MULTISITE) er interessert i å teste multisite for dette prosjektet, så sett til falskt. * / define ('WP_ALLOW_MULTISITE' Definer ('MULTISITE', sant), definer ('DOMAIN_CURRENT_SITE', WP_TESTS_DOMAIN), definer ('PATH_CURRENT_SITE', '/'); d efine ('SITE_ID_CURRENT_SITE', 1); define ('BLOG_ID_CURRENT_SITE', 1); $ table_prefix = 'wp_'; For å kontrollere at du har installert testene riktig, kan du kjøre følgende kommando i Terminal:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit alle
Hvis du får feil, er det fordi WordPress-tester prøver å bruke en stikkontakt til MySQL-databasen i stedet for den som brukes av MAMP. For å fikse dette, må vi opprette en symbolsk lenke fra MAMPs stikkontakt til stedet på disken som enhetstester bruker. Utsted følgende kommandoer i terminalsesjonen din:
$ sudo mkdir / var / mysql $ sudo ln-s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock $ sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock / var / mysql / mysql.sock
Nå, prøv å kjøre testene igjen, og du bør se noe som følgende skjermbilde.
Igjen kan kjørelengdeet ditt variere basert på plattformen som du bruker, så du kan dele erfaringen din i kommentarene eller til og med forplikte deg til README-filen på GitHub også, slik at andre kan ha et referansepunkt.
På dette tidspunktet er vi klare til å begynne å bygge pluginet vårt og skrive våre enhetstester. Ovennevnte kode er lagt til i GitHub, og jeg skal bygge den ut når vi arbeider gjennom neste artikkel i serien. I mellomtiden må du sørge for at du får miljøoppsettet og at du er klar til å begynne utvikling. I neste artikkel begynner vi faktisk å skrive tester, bygge pluginet vårt, og se hele prosjektet kommer sammen fra start til slutt.
