Share
We hebben gekeken naar unit testing voor de ontwikkeling van WordPress. Aan de hand van praktijkvoorbeelden hebben we bekeken hoe unit testing eruit ziet voor zowel plug-ins als voor thema's; we hebben echter niet echt gesproken over de theorie achter het testen van eenheden.
Dat wil zeggen dat we niet op hoog niveau hebben gekeken naar wat het is, waarom het nuttig is en hoe we het in onze workflow kunnen opnemen. In de volgende reeks artikelen gaan we eenheidstesten definiëren, de belangrijkste voordelen ervan dekken, waarom we de moeite zouden moeten nemen om het te doen, en enkele van de bronnen die beschikbaar zijn om te gebruiken in ons werk.
Hoewel er geen code is om door te werken voor deze specifieke tutorial, moet het een solide basis bieden waarop de praktische toepassing van de vorige artikelen berust.
Voordat ik in het artikel duiken, zou ik denken dat het belangrijk is om na te denken over de redenen waarom je het testen van thema's en plug-ins helemaal niet zou moeten doen.
Tot voor kort werd WordPress voornamelijk gezien als een blogplatform en als een contentmanagementsysteem. Het doet beide heel goed, maar naarmate ontwikkelaars hun rijke API ontdekken, wordt het steeds populairder om bepaalde soorten applicaties te bouwen met behulp van WordPress als het onderliggende platform.
Bovendien zijn thema's meer dan skins voor een website - ze zijn meer dan een stylesheet en een paar sjabloonbestanden voor het weergeven van gegevens. Sterker nog, nu, misschien wel meer dan ooit, wikkelen hele teams tijd (en zelfs hun brood) aan het maken van thema's voor WordPress. Dus laat het woord 'thema' u niet misleiden - thema's zijn als toepassingen voor WordPress. Ze voegen functionaliteit toe, ze verwerken gegevens vooraf en verwerken postprocessen en introduceren vaak aanzienlijke functionaliteit in WordPress, veel meer dan alleen maar uw website een opknapbeurt te geven.
Ten slotte zijn plug-ins bijna meer applicatie-achtig van aard dan thema's. Beschouw het op deze manier: plug-ins breiden de kern van WordPress uit en ze werken vaak onafhankelijk van thema's. In plaats daarvan voegen ze gloednieuwe functies toe aan de kern van WordPress, waar alle thema's van kunnen profiteren.
Ik zeg dit alles om enig inzicht te geven in waarom eenheidstesten - zoals we op het punt staan te ontdekken - vele voordelen kunnen opleveren omdat het wordt gebruikt in de context van complexere thema's en plug-ins.
We hebben dit kort besproken in het eerste artikel in de serie. Ik wil niet volledig onthullen wat er al is geschreven, dus ik zal de punten hier samenvatten:
Maar dat krabt alleen maar aan de oppervlakte.
Om de eenheden van uw thema of plug-in echt te begrijpen, moet u nadenken over wat een thema samenstelt. Meestal is het een combinatie van:
Hoewel er frameworks voor het testen van eenheden zijn specifiek voor JavaScript, zullen we ons meer richten op het PHP-aspect van WordPress-ontwikkeling. Immers, als het niet voor de functionaliteit aan de serverzijde was, zou er heel weinig unieke functionaliteit in WordPress worden geïntroduceerd.
Met dat gezegd, er zijn meerdere manieren om een eenheid te definiëren, maar ik durf te wedden dat de meeste mensen een eenheid definiëren als een functie. Grotendeels, dat klopt, maar het betekent niet dat onze functies de meest optimale eenheden zijn om te testen. Functies bestaan bijvoorbeeld vaak uit meerdere blokken - misschien loops, misschien conditionals of misschien oproepen naar andere functies.
Hoe het ook zij, er zijn vaak kleinere functionaliteiteenheden binnen de methoden.
Dus is het echt juist om te zeggen dat het testen van eenheden het testen van elke functie is die een thema vormt? Niet echt. Omdat een enkel codeblok - of in sommige gevallen één enkele verklaring - verantwoordelijk is voor het bereiken van een specifieke taak, deze zou ware eenheden van code vormen.
En als we eenheidstests moeten schrijven, hoe schrijven we tests voor de eenheden die binnen onze functies bestaan?
Bedenk dat ik eerder in de serie zei:
Dit is waar een van de grootste verschuivingen in de testbare code van de schrijfeenheid optreedt: je breekt eenheden met functionaliteit uit in het kleinste atomische stuk dat mogelijk is. Natuurlijk resulteert dit vaak in een groot aantal zeer kleine functies, maar dat is een slechte zaak?
Daarbij heeft elke functie echt één doel. En in de veronderstelling dat je functie één ding doet, zijn er maar zo veel manieren om de functie een naam te geven die uiteindelijk kan resulteren in veel leesbaardere code.
Natuurlijk is er een compromis omdat u tijdens het schrijven van deze extra functies misschien nog een paar regels code zult invoeren, maar als u werkt aan een product met een team van andere mensen dat door duizenden klanten wordt gebruikt, u moet uzelf afvragen of de aanvullende code de kwaliteit waard is die u kunt winnen bij het correct testen van uw werk. Goed gedaan, je team moeten in staat zijn om gemakkelijker de logica van de code te volgen en het product zal een kwaliteitsniveau hebben dat vaak moeilijk te bereiken is zonder eenheidstests te schrijven.
Een belangrijk ding om te erkennen over unit tests is dat ze niet afhankelijk zijn van elkaar. Een test met één eenheid zou één en slechts één ding moeten testen. Bovendien betekent dit dat een unit-test eigenlijk maar één enkele bewering moet bevatten (maar er zijn uitzonderingen die hier worden aangetoond).
Let op: het doel van een unit-test is om de kwaliteit van een enkele code-eenheid te evalueren. Sommige eenheden accepteren argumenten, sommige eenheden niet, sommige eenheden zullen waarden teruggeven, andere niet. Hoe het ook zij, je unit-test moet alle gevallen evalueren. Een enkele code-eenheid zal zelden een enkele test hebben.
In plaats daarvan zou ik zeggen dat een goede vuistregel is dat het aantal tests dat is gekoppeld aan een code-eenheid exponentieel is gebaseerd op het aantal ingangen dat wordt geaccepteerd.
Bijvoorbeeld:
Heb je zin? De sleutel is hier weghalen dat je significant meer testen zult hebben dan er eenheden zijn; er is geen verhouding van 1: 1.
Tot slot, bij het testen van eenheden, zult u vaak het woord "test suite" of "suite" zien gebruikt bij het bespreken van de tests. Dit kan variëren op basis van de context waarin het testen plaatsvindt; nochtans, wanneer het werken met WordPress, verwijst dit gewoonlijk naar een inzameling van eenheidsonderzoeken.
Laten we zeggen dat u een bestand heeft dat verantwoordelijk is voor het testen van alle functionaliteit rond het schrijven en publiceren van een bericht. Dit bestand zou het testsuite voor berichten zijn. Makkelijk genoeg, toch? Het is belangrijk om deze terminologie te begrijpen als u dit in verder lezen tegenkomt, omdat het enigszins kan verschillen als u in bijvoorbeeld Rails of .NET werkt..
Ten slotte is unit testing geen nieuwe methodologie en het is niet strikt beperkt tot PHP. Sterker nog, unit testing (of test-driven ontwikkeling als geheel) bestaat al meer dan een decennium.
Je kunt unit testing frameworks vinden voor Java, .NET, Rails, PHPUnit (uiteraard), enzovoort.
Maar de acceptatie ervan is gemengd - sommige mensen leven er mee en sterven eraan, anderen haten het, en dan zijn er diegenen onder ons die dit willen beginnen, maar moeten de praktische toepassing van het in een bestaand project brengen en begrijpen van de hoeveelheid refactoring die dit kan vereisen.
, Voor zover het theorie betreft, we zijn net begonnen.
In het volgende artikel zullen we specifiek ingaan op de belangrijkste voordelen van het testen van eenheden en hoe deze kunnen worden terugverdiend in onze op WordPress gebaseerde ontwikkeling. We zullen ook de voordelen onderzoeken die eenheidstests bieden voor architectuur, ontwerp en documentatie.
Uiteraard is het testen van eenheden niet zonder de nadelen, dus we zullen ook naar die kijken.
Accentsconagua