Share
Beroende på din bakgrund kan eller kanske du inte har hört talas om enhetsprovning, testdriven utveckling, beteendestyrd utveckling eller någon annan typ av testmetodik. Ofta tillämpas dessa metoder i samband med större mjukvarusystem eller applikationer och mindre i samband med WordPress-baserade projekt (även om det är blir bättre!)
Uppriktigt sagt är utvecklingsgemenskapen lite uppdelad i automatiserad mjukvarutestning. Du har några personer som tycker att du borde ha test för 100% av hela din kod. Vissa tror att 80% är tillräcklig, cirka 50% och vissa är nöjda med 20% eller så. Vad som än är fallet handlar det inte om att det här är ett argument för hur mycket test du borde ha i ditt projekt, eller att det tar ställning till allmän programvarutestning.
I stället ska vi titta på vad som krävs för att komma igång med enheten som testar dina WordPress-utvecklingsprojekt. Vi kommer att närma sig denna serie ur ett absolut nybörjarperspektiv så att vi kan förstå fördelarna med enhetstestning och hur vi konfigurerar vår miljö för att stödja enhetsprovningsbibliotek så att vi kan börja göra det i vårt framtida arbete. Slutligen kommer allt detta att ske genom att bygga och testa ett enkelt testbart plugin från grunden.
Innan vi börjar med att ställa in vår miljö och skriva vilken kod som helst, låt oss definiera exakt vilken enhetstestning, varför det är värt att göra och hur man börjar med att integrera det i våra projekt.
På hög nivå refererar enhetsprovning till att man testar vissa funktioner och områden - eller enheter - av vår kod. Detta ger oss möjlighet att verifiera att våra funktioner fungerar som förväntat. Det vill säga att för vilken funktion som helst och givet en uppsättning ingångar kan vi avgöra om funktionen returnerar de korrekta värdena och kommer att hantera felfunktioner under genomförandet, om en felaktig ingång tillhandahålls.
I slutändan hjälper det oss att identifiera fel i våra algoritmer och / eller logik för att förbättra kvaliteten på koden som komponerar en viss funktion. När du börjar skriva fler och fler tester slutar du skapa en serie test som du kan köra när som helst under utveckling för att ständigt verifiera kvaliteten på ditt arbete.
En andra fördel att närma sig utveckling från enhetsprovningsperspektiv är att du sannolikt kommer att skriva kod som är lätt att testa. Eftersom enhetstestning kräver att din kod enkelt kan testas betyder det att din kod måste stödja denna typ av utvärdering. Som sådan är du mer sannolikt att ha ett större antal mindre, mer fokuserade funktioner som ger en enda operation på en uppsättning data i stället för stora funktioner som utför ett antal olika operationer.
En tredje fördel för att skriva fasta enhetstest och väl testad kod är att du kan förhindra framtida förändringar från att bryta funktionaliteten. Eftersom du testar din kod när du presenterar din funktionalitet kommer du att börja utveckla en serie testfall som kan köras varje gång du arbetar med din logik. När ett misslyckande inträffar vet du att du har något att ta itu med.
Naturligtvis kommer detta på bekostnad av att investera tid för att skriva en serie test tidigt under utveckling, men när projektet växer kan du helt enkelt köra de tester som du har utvecklat för att säkerställa att befintlig funktionalitet inte bryts när ny funktionalitet är infördes.
Ett av de bästa sätten att komma igång med enhetsprovning är att göra det i samband med en praktisk tillämpning. Under hela denna tvådelade serie kommer vi att bygga en enkel plugin och skriva tester för att täcka all funktionalitet.
Låt oss först planera projektet: Vi ska skriva ett litet plugin som lägger till ett enkelt meddelande högst upp i ett enda inlägg som välkomnar användaren baserat på hur de har hittat ett visst blogginlägg. Idén är väldigt lik Welcome Reader men det kommer inte att innehålla nästan lika mycket funktionalitet - vi bygger helt enkelt en demo för att lära känna insatserna av testning.
Hur som helst, här är hur plugin kommer att fungera:
Riktigt nog, eller hur? Detta kommer också att ge en grund för att lägga till anpassade meddelanden för andra tjänster och vidareutveckla våra testningsförmågor om du vill göra det.
För att kunna testa vår kod måste vi ha ett bibliotek från tredje part som vi ingår i vårt projekt som faktiskt ska utföra de tester vi skriver. I denna serie ska vi använda PHPUnit. Du kan ta en kopia av det här.
Därefter måste vi förbereda vår utvecklingsmiljö, stubba ut pluginet och inkludera nödvändiga bibliotek för att testa vår kod. Denna artikel antar att du redan har en funktionell WordPress-installation igång.
Så, först, låt oss förbereda plugin katalogen:
Här är skelettet för plugin som vi ska skapa:
/ * Plugin Name: Hej Reader Plugin URI: http://github.com/tommcfarlin/Hello-Reader Beskrivning: En enkel plugin som används för att visa demonstrationsprovning i samband med WordPress. Version: 1.0 Författare: Tom McFarlin Författare URI: http://tom.mcfarl.in Författare Email: [email protected] Licens: Copyright 2012 Tom McFarlin ([email protected]) Detta program är fri programvara; Du kan omfördela det och / eller ändra det enligt villkoren i GNU General Public License, version 2, som publicerad av Free Software Foundation. Programmet distribueras i hopp om att det kommer att vara användbart, men UTAN NÅGOT GARANTI. utan ens den underförstådda garantin om SÄLJBARHET eller EGNETHET FÖR ET SÄRSKILT SYFTE. Se GNU General Public License för mer information. Du borde ha fått en kopia av GNU General Public License tillsammans med det här programmet. om inte, skriv till Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * / // Skapa bara en instans av plugin om den inte redan finns i GLOBALS om (! array_key_exists ("hello-reader", $ GLOBALS)) class Hello_Reader function __construct () // endconstructor // end class // Spara en referens till plugin i GLOBALS så att våra enhetstester kan komma åt det $ GLOBALS ['hejläsare'] = ny Hello_Reader (); // slut om
Vid denna tidpunkt bör du kunna navigera till "Plugins" i din WordPress Dashboard och se en post för "Hello Reader." Självklart gör det här pluginet inte någonting just nu - vi kommer att fokusera på det (liksom varför vi utnyttjar $ GLOBALS array) i nästa artikel.
Låt oss slutligen konfigurera testramen så att vi kan skriva våra test. Först måste vi installera PHPUnit och då måste vi installera WordPress-testen.
Notera: Nästa avsnitt kräver att du arbetar med terminalen och kommer sannolikt att kräva att du utfärdar några kommandon för att skapa symboliska länkar. Jag har försökt att göra det så enkelt och enkelt som möjligt, men varje operativsystem och konfiguration kommer att vara annorlunda. Var vänlig följ noga och jag uppmanar dig att dela dina instruktioner för operativsystem i kommentarerna.
PHPUnit är ett enhetstestramverk för PHP. WordPress-testen och det ramverk som vi ska använda för att skriva våra WordPress-test beror på detta. Tyvärr varierar installationen baserat på din plattform. Jag kör för närvarande Mac OS X Lion med MAMP Pro och PHP 5.3.6. Om du kör en annan plattform, var noga med att hänvisa till dokumentationen och / eller gärna dela dina steg i kommentarerna.
Öppna först en terminal och uppdateringspäron (det här är den anläggning som vi ska använda för att installera PHPUnit):
$ cd /Applications/MAMP/bin/php/php5.3.6/bin$ sudo ./pear uppgraderingspäron
Därefter instruerar Pear att använda repositories som vi ska ange i terminal:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear config-set auto_discover 1
Efter det, installera Pear genom att utfärda följande kommando:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear installera pear.phpunit.de/PHPUnit
Detta installerar PHPUnit inom ramen för din MAMP-installation. För att testa det, kör följande kommando i terminalsessionen:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit --version
Därefter ska följande meddelande visas:
PHPUnit 3.6.11 av Sebastian Bergmann.
Notera: Om du råkar få ett terminalfel som nämner "unserialize ()", då är det en skillnad mellan pärkonfigurationen och din version av päron. För att lösa problemet, utfärda följande kommando (det här renar bara om filen om du vill återställa den senare):
$ /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf/Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.old
Nu när vi har installerat PHPUnit och arbetar, är det dags att konfigurera WordPress Testing Framework. Du kan ta tag i paketet från GitHub. Om du är bekväm att klona förvaret, känner du dig fri att göra det. annars, helt enkelt ladda ner ett arkiv av projektet och extrahera det i testa katalog som vi skapade tidigare i den här artikeln.
Innan vi kör testen måste vi skapa en config-fil för att köra WordPress-test. Det här är precis som att redigera wp-config.php filen med en ny WordPress-installation, men vi gör det för en testdatabas istället. Nedan har jag klistrat in min konfigurationsfil och lagt till kommentarer. Jag kommer att vara säker på att begå detta till GitHub-arkivet i den här artikeln.
Accentsconagua
/ * Vägen till WordPress-kodbasen i förhållande till platsen för dessa test. Eftersom de ingår i vårt plugin hänvisar vi till några kataloger ovan. * / define ('ABSPATH', '... / ... / ... / ... / ... /'); / * Namnet på databasen för att köra testen. Se till att det här är en databas för testning eftersom den är skapad och trashad under test. * / define ("DB_NAME", "throwaway"); / * Vanliga referenser för en lokal databas. * / define ('DB_USER', 'root'); define ('DB_PASSWORD', '); define (' DB_HOST ',' localhost '); definiera (' DB_CHARSET ',' utf8 '); definiera (' DB_COLLATE ','); define ('WPL_DISPLAY', true); define ('WP_TESTS_DOMAIN', 'localhost'); definiera ('WP_TESTS_EMAIL','[email protected] Definiera ('WP_TESTS_NETWORK_TITLE', 'Test Network'), definiera ('WP_TESTS_SUBDOMAIN_INSTALL', definiera ('WP_TESTS_TITLE', 'Test Blog'); / * Oroa dig inte för att testa nätverk eller underdomäner. false); $ base = '/'; / * Cron försöker göra en HTTP-förfrågan till bloggen, som alltid misslyckas, eftersom testen endast körs i CLI-läge * / define ('DISABLE_WP_CRON' true); / * Inte heller (WP_ALLOW_MULTISITE) define ('WP_TESTS_BLOGS', 'första, andra, tredje, fjärde'); om (WP_ALLOW_MULTISITE), om det är WP_ALLOW_MULTISITE Definiera ('MULTISITE', true), definiera ('DOMAIN_CURRENT_SITE', WP_TESTS_DOMAIN), definiera ('PATH_CURRENT_SITE', '/'); d) definiera ('WOMB_INSTALL' efine ("SITE_ID_CURRENT_SITE", 1); definiera ('BLOG_ID_CURRENT_SITE', 1); $ table_prefix = 'wp_'; För att verifiera att du har installerat testerna korrekt kan du köra följande kommando i din terminal:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit alla
Om du råkar få ett fel beror det på att WordPress-testen försöker använda en uttag till MySQL-databasen i stället för den som används av MAMP. För att åtgärda detta måste vi skapa en symbolisk länk från MAMPs uttag till platsen på disken som enhetstesterna använder. Utfärda följande kommandon i terminalsessionen:
$ 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
Försök nu att köra testen igen och du bör se något som följande skärmdump.
Återigen kan din körsträcka variera beroende på vilken plattform som du använder, så gärna dela din upplevelse i kommentarerna eller ens åta dig till README-filen på GitHub så att andra kan ha en referenspunkt.
Vid denna tidpunkt är vi redo att börja bygga vårt plugin och skriva våra enhetstester. Ovanstående kod har lagts till i GitHub och jag kommer att bygga den ut när vi arbetar igenom nästa artikel i serien. Under tiden, se till att du får din miljöinställning och att du är redo att börja utveckla. I nästa artikel börjar vi faktiskt skriva test, bygga vårt plugin och se hela projektet samlas från början till slut.
