Share
Afhankelijk van uw achtergrond hebt u mogelijk wel of niet gehoord van unit-testing, testgestuurde ontwikkeling, gedragsgestuurde ontwikkeling of een ander type testmethodologie. Vaak worden deze methodologieën toegepast in de context van grotere softwaresystemen of -toepassingen en minder in de context van op WordPress gebaseerde projecten (hoewel het is beter worden!)
Eerlijk gezegd is de ontwikkelgemeenschap een beetje verdeeld over geautomatiseerde softwaretests - je hebt een aantal mensen die denken dat je 100% van je code moet testen, sommige geloven dat 80% voldoende is, ongeveer 50%, en sommige zijn tevreden met 20% of zo. Hoe het ook zij, dit artikel gaat niet over het argument van het niveau van tests dat u in uw project zou moeten hebben, noch neemt het een standpunt in over algemene softwaretests..
In plaats daarvan gaan we kijken wat er nodig is om aan de slag te gaan met het testen van uw WordPress-ontwikkelingsprojecten. We gaan deze serie benaderen vanuit het perspectief van een absolute beginner, zodat we de voordelen van het testen van eenheden kunnen begrijpen en hoe we onze omgeving kunnen configureren om bibliotheken voor unit testing te ondersteunen, zodat we dit in ons toekomstige werk kunnen doen. Ten slotte wordt dit allemaal gedaan door een eenvoudige, testbare plug-in van de grond af op te bouwen en te testen.
Voordat we aan de slag gaan met het instellen van onze omgeving en het schrijven van een code, laten we definiëren wat testen van eenheden is, waarom het de moeite waard is om te doen en hoe we kunnen beginnen met de integratie ervan in onze projecten..
Op een hoog niveau verwijst unit test naar de praktijk van het testen van bepaalde functies en gebieden - of eenheden - van onze code. Dit geeft ons de mogelijkheid om te controleren of onze functies werken zoals verwacht. Dat wil zeggen dat we voor elke functie en gegeven een reeks ingangen kunnen bepalen of de functie de juiste waarden retourneert en tijdens de uitvoering van de uitvoering sierlijk fouten zullen afhandelen als er ongeldige invoer wordt gegeven.
Uiteindelijk helpt dit ons om fouten in onze algoritmen en / of logica te identificeren om de kwaliteit van de code die een bepaalde functie samenstelt te helpen verbeteren. Naarmate u meer en meer tests begint te schrijven, maakt u uiteindelijk een reeks tests die u op elk moment tijdens de ontwikkeling kunt uitvoeren om voortdurend de kwaliteit van uw werk te controleren..
Een tweede voordeel van het benaderen van de ontwikkeling vanuit het oogpunt van unit testing is dat u waarschijnlijk een code schrijft die gemakkelijk te testen is. Aangezien testen van eenheden vereist dat uw code gemakkelijk te testen is, betekent dit dat uw code dit specifieke type evaluatie moet ondersteunen. Als zodanig hebt u meer kans op een groter aantal kleinere, meer gerichte functies die één bewerking op een set gegevens bieden in plaats van grote functies die een aantal verschillende bewerkingen uitvoeren.
Een derde voordeel voor het schrijven van solide testeenheden en goed geteste code is dat u kunt voorkomen dat toekomstige wijzigingen de functionaliteit breken. Aangezien u uw code test terwijl u uw functionaliteit introduceert, gaat u beginnen met het ontwikkelen van een reeks testcases die elke keer dat u aan uw logica werkt, kunnen worden uitgevoerd. Wanneer een fout optreedt, weet u dat u iets te melden heeft.
Natuurlijk gaat dit ten koste van het investeren van tijd om een reeks testen vroeg in de ontwikkeling te schrijven, maar naarmate het project groeit, kunt u eenvoudig de tests uitvoeren die u hebt ontwikkeld om ervoor te zorgen dat de bestaande functionaliteit niet wordt verbroken wanneer nieuwe functionaliteit wordt gebruikt introduceerde.
Een van de beste manieren om aan de slag te gaan met het testen van eenheden is om dit te doen in de context van een praktische toepassing. In deze tweedelige serie bouwen we een eenvoudige plug-in en schrijftests om alle functionaliteit te dekken.
Laten we eerst het project plannen: we gaan een kleine plug-in schrijven waarin een eenvoudig bericht boven aan een bericht wordt geplaatst waarin de gebruiker wordt verwelkomd op basis van hoe ze een specifiek blogbericht hebben gevonden. Het idee is vergelijkbaar met Welcome Reader, maar het bevat niet zo veel functionaliteit, we bouwen gewoon een demo om de ins en outs van testen te leren.
Hoe dan ook, hier is hoe de plug-in werkt:
Eenvoudig genoeg, toch? Dit biedt ook een basis voor het toevoegen van aangepaste berichten voor andere services en breidt onze testmogelijkheden voor eenheden verder uit als u dat wilt.
Om onze code te testen, hebben we een externe bibliotheek nodig die we opnemen in ons project en die de tests die we schrijven daadwerkelijk zal uitvoeren. In deze serie gaan we PHPUnit gebruiken. Je kunt hier een kopie van krijgen.
Vervolgens moeten we onze ontwikkelomgeving voorbereiden, onze plug-in uitpluizen en de nodige bibliotheken opnemen om onze code te testen. Dit artikel gaat ervan uit dat je al een functionele WordPress-installatie hebt geïnstalleerd.
Laten we eerst de plugin-directory voorbereiden:
Dit is het skelet voor de plug-in die we gaan maken:
/ * Naam van de plug-in: Hello Reader Plugin URI: http://github.com/tommcfarlin/Hello-Reader Beschrijving: Een eenvoudige plug-in die wordt gebruikt om eenheidstests in de context van WordPress te demonstreren. Versie: 1.0 Auteur: Tom McFarlin Auteur URI: http://tom.mcfarl.in Auteur Email: [email protected] Licentie: Copyright 2012 Tom McFarlin ([email protected]) Dit programma is gratis software; je kunt het herdistribueren en / of wijzigen onder de voorwaarden van de GNU General Public License, versie 2, zoals gepubliceerd door de Free Software Foundation. Dit programma wordt verspreid in de hoop dat het nuttig zal zijn, maar ZONDER ENIGE GARANTIE; zonder zelfs de impliciete garantie van VERKOOPBAARHEID of GESCHIKTHEID VOOR EEN BEPAALD DOEL. Zie de GNU General Public License voor meer details. Je zou samen met dit programma een kopie van de GNU General Public License moeten hebben ontvangen; zo niet, schrijf dan naar de Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 VS * / // Maak alleen een exemplaar van de plug-in als deze nog niet bestaat in GLOBALS als (! array_key_exists ('hello-reader', $ GLOBALS)) class Hello_Reader function __construct () // end constructor // end class // Bewaar een verwijzing naar de plug-in in GLOBALS zodat onze unit-tests er toegang tot hebben $ GLOBALS ['hello-reader'] = nieuwe Hello_Reader (); // stop als
Op dit punt zou je moeten kunnen navigeren naar de "Plug-ins" in je WordPress Dashboard en een bericht zien voor "Hallo lezer". Het is duidelijk dat deze plug-in nog niets doet - daar zullen we ons op focussen (en ook waarom we gebruik maken van de $ GLOBALS array) in het volgende artikel.
Laten we ten slotte het testraamwerk zo instellen dat we onze tests kunnen schrijven. Eerst moeten we PHPUnit installeren en dan moeten we de WordPress-tests installeren.
Notitie: In de volgende sectie moet u wat werk met de terminal doen en waarschijnlijk moet u een paar opdrachten uitvoeren om symbolische koppelingen te maken. Ik heb geprobeerd dit zo eenvoudig en gemakkelijk mogelijk te maken, maar elk besturingssysteem en elke configuratie zal anders zijn. Volg deze aandachtig en ik nodig u uit om uw instructies voor uw besturingssystemen te delen in de opmerkingen.
PHPUnit is een unit test framework-pakket specifiek voor PHP. De WordPress Tests en het raamwerk dat we gaan gebruiken voor het schrijven van onze WordPress-tests zijn hiervan afhankelijk. Helaas varieert de installatie op basis van uw platform. Ik heb momenteel Mac OS X Lion met MAMP Pro en PHP 5.3.6. Als u een ander platform gebruikt, moet u de documentatie raadplegen en / of uw stappen in de opmerkingen delen.
Open eerst een terminal en update peer (dit is de faciliteit die we zullen gebruiken om PHPUnit te installeren):
$ cd /Applications/MAMP/bin/php/php5.3.6/bin$ sudo ./pear upgrade peer
Geef Pear vervolgens de opdracht om repository's te gebruiken die we in terminal zullen specificeren:
$ sudo / Applications/MAMP/bin/php/php5.3.6/bin/pear config-set auto_discover 1
Hierna installeer je Pear door de volgende opdracht te geven:
$ sudo / Applications/MAMP/bin/php/php5.3.6/bin/pear installeren pear.phpunit.de/PHPUnit
Hiermee wordt PHPUnit geïnstalleerd binnen de context van je MAMP-installatie. Om het uit te testen, voert u de volgende opdracht uit in uw terminalsessie:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit --version
Waarna het volgende bericht moet worden weergegeven:
PHPUnit 3.6.11 door Sebastian Bergmann.
Notitie: Als u toevallig een terminalfout krijgt met de vermelding "unserialize ()", is er een verschil tussen de peerconfiguratie en uw versie van peer. Geef de volgende opdracht om dit probleem op te lossen (dit geeft een nieuwe naam aan het bestand als u het later wilt herstellen):
$ /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.old
Nu PHPUnit is geïnstalleerd en werkt, is het tijd om het WordPress-testraamwerk in te stellen. Je kunt het pakket van GitHub pakken. Als je je prettig voelt bij het klonen van de repository, voel je dan vrij om dat te doen; download anders gewoon een archief van het project en pak het uit in de test map die we eerder in dit artikel hebben gemaakt.
Voordat we de tests daadwerkelijk uitvoeren, moeten we een configuratiebestand maken voor het uitvoeren van WordPress-tests. Dit is precies hetzelfde als het bewerken van de wp-config.php bestand met een nieuwe WordPress-installatie, maar in plaats daarvan doen we het voor een testdatabase. Hieronder heb ik mijn configuratiebestand geplakt en opmerkingen toegevoegd. Ik zal dit zeker ook verbinden met de GitHub-repository van dit artikel.
Accentsconagua
/ * Pad naar de WordPress-codebasis met betrekking tot de locatie van deze tests. Omdat ze bij onze plug-in worden geleverd, verwijzen we naar een paar mappen hierboven. * / define ('ABSPATH', '... / ... / ... / ... / ... /'); / * De naam van de database voor het uitvoeren van de tests. Zorg ervoor dat dit een database is die alleen voor testen wordt gebruikt, omdat deze is gemaakt en in de prullenbak is geplaatst tijdens tests. * / define ('DB_NAME', 'throwaway'); / * De gebruikelijke referenties voor een lokale database. * / define ('DB_USER', 'root'); define ('DB_PASSWORD', "); define ('DB_HOST', 'localhost'); define ('DB_CHARSET', 'utf8'); define ('DB_COLLATE',"); define ('WPLANG', '); define (' WP_DEBUG ', true); define (' WP_DEBUG_DISPLAY ', true); define (' WP_TESTS_DOMAIN ',' localhost '); define (' WP_TESTS_EMAIL ','[email protected] '); define (' WP_TESTS_TITLE ',' Test Blog '); / * Maak je geen zorgen over het testen van netwerken of subdomeinen, dus instellen op false. * / define (' WP_TESTS_NETWORK_TITLE ',' Test Network '); define (' WP_TESTS_SUBDOMAIN_INSTALL ', false); $ base = '/'; / * Cron probeert een HTTP-verzoek naar de blog te maken, wat altijd faalt, omdat tests alleen in de CLI-modus worden uitgevoerd * / define ('DISABLE_WP_CRON', true); / * Ook niet geïnteresseerd in het testen van multisite voor dit project, dus instellen op false. * / define ('WP_ALLOW_MULTISITE', false); if (WP_ALLOW_MULTISITE) define ('WP_TESTS_BLOGS', 'first, second, third, fourth'); if (WP_ALLOW_MULTISITE &&! gedefinieerd ('WP_INSTALLING')) define ('SUBDOMAIN_INSTALL', WP_TESTS_SUBDOMAIN_INSTALL); define ('MULTISITE', true); define ('DOMAIN_CURRENT_SITE', WP_TESTS_DOMAIN); define ('PATH_CURRENT_SITE', '/'); d efine ('SITE_ID_CURRENT_SITE', 1); define ('BLOG_ID_CURRENT_SITE', 1); $ table_prefix = 'wp_'; Om te controleren of u de tests correct hebt geïnstalleerd, kunt u de volgende opdracht uitvoeren in uw Terminal:
$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit alles
Als u toevallig een foutmelding krijgt, komt dat omdat de WordPress-tests een socket proberen te gebruiken in de MySQL-database in plaats van degene die wordt gebruikt door MAMP. Om dit te verhelpen, moeten we een symbolische koppeling maken vanuit de socket van MAMP naar de locatie op schijf die door de unittests wordt gebruikt. Geef de volgende opdrachten in uw terminalsessie:
$ 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
Probeer nu de tests opnieuw uit te voeren en je ziet iets als het volgende screenshot.
Nogmaals, je aantal kilometers kan variëren op basis van het platform dat je gebruikt, dus voel je vrij om je ervaringen te delen in de opmerkingen of zelfs te committeren aan het README-bestand op GitHub, zodat anderen een referentiepunt kunnen hebben.
Op dit moment zijn we klaar om onze plug-in te bouwen en onze unit-tests te schrijven. De bovenstaande code is toegevoegd aan GitHub en ik zal het uitwerken terwijl we door het volgende artikel in de serie werken. Zorg er in de tussentijd voor dat u uw omgeving instelt en dat u klaar bent om met de ontwikkeling te beginnen. In het volgende artikel beginnen we met het schrijven van tests, het bouwen van onze plug-in en zien we hoe het hele project van begin tot eind bij elkaar komt.
