Share
In het laatste artikel begonnen we te praten over de theorie van unit testing in WordPress. In het bijzonder hebben we onze werkzaamheden met betrekking tot het testen van eenhedensthema's en plug-ins besproken en vervolgens begonnen met het bespreken van code-eenheden, hoe dit onze testen beïnvloedt en we hebben unittesten in de grotere wereld van softwareontwikkeling beoordeeld.
We gaan door met het bespreken van de theorie van eenheidstesten in WordPress, maar gaan dit doen vanuit het perspectief van hoe het kan helpen problemen te identificeren, architectuur te sturen, het project te documenteren en meer.
Denk aan eerder in deze serie dat de traditionele manier om eenheidstests uit te voeren dit is:
Ja, de eerste stap is een beetje dogmatisch. Waarom zou je minuten verspillen met iets waarvan je weet dat het gaat mislukken, toch? Toch krijg je het idee. Maar wanneer je deze specifieke techniek gaat toepassen op ontwikkeling, zul je ontdekken dat je een bepaald ritme ontwikkelt voor het schrijven van je code en dat maakt deel uit van het hele doel.
Maar dat is slechts de helft - met unit-testen kunt u problemen eerder in de ontwikkeling opsporen.
Om dit te begrijpen, is het waarschijnlijk het beste om terug te gaan naar het idee.
Laten we zeggen dat u werkt aan een functie voor een op WordPress gebaseerd project waarbij u gebruikers een gebruikersaccount laat maken zonder zich daadwerkelijk aan te melden bij het WordPress-dashboard. Hierbij wordt ervan uitgegaan dat u een paginasjabloon hebt ingesteld voor de registratie, de vereiste validatie en de code voor het genereren van wachtwoorden en e-mails.
Je laadt de pagina in je browser, probeert een paar gebruikers te maken - sommige met hetzelfde e-mailadres, sommige met ongepaste wachtwoorden, sommige met illegale karakters, etc. Je snapt het - er zijn n-aantal manieren voor de validatie voorbijgaan en falen. Dit is moeilijk! Dit betekent dat elke keer dat de gebruikersregistratiefunctie wordt gewijzigd, u hetzelfde n-aantal registraties moet uitvoeren om er zeker van te zijn dat er niets kapot is.
Of u kunt een reeks tests schrijven om ervoor te zorgen en deze allemaal uitvoeren telkens wanneer de code verandert.
Dus, ja, het schrijven van eenheidscontroletests kan van tevoren veel tijd in beslag nemen, maar kijk naar de hoeveelheid tijd die wordt bespaard telkens wanneer u een code-eenheid wijzigt. Het is het zeker waard en dit kan al vroeg helpen problemen te identificeren - dat wil zeggen, voordat het in productie wordt gebracht - dat had kunnen worden gemist omdat iemand vergat één poging van de test te simuleren.
Als het gaat om het schrijven van eenheidscontroles, verbetert u niet alleen de kwaliteit van uw code door ervoor te zorgen dat deze ook werkt, maar levert u inherent ontwikkelaargerichte documentatie op.
Als u eenheidstests uitvoert voor de functionaliteit die u in uw product wilt inbouwen, levert u documentatie over hoe functies bedoeld zijn om te werken, wanneer ze moeten falen en wanneer ze moeten worden doorgegeven.
Er zijn enkele aannames die hieraan ten grondslag liggen: specifiek dat u uw functies en de bijbehorende tests logisch benoemt en groepeert en dat u elke functie goed test.
Via PHPUnit maken de WordPress Unit Tests het eenvoudig om beweringen uit te voeren die gemakkelijk te lezen zijn. U stelt eenvoudig assertTrue, assertFalse of andere beweringen beschikbaar over de functies die uw project samenstellen.
In navolging van ons voorbeeld hierboven betekent dit dat u een functie kunt schrijven om ervoor te zorgen dat de gebruikersregistratiefunctie mislukt wanneer u probeert te registreren met een leeg e-mailadres:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Een eenvoudig voorbeeld misschien, maar het punt blijft: uw code wordt zelfdocumenterend en vereist alleen dat u duidelijke eenheidscontroles schrijft.
Misschien is een van de meest ingetogen voordelen van unit testing dat het kan helpen de architectuur van uw project te sturen. Doorgaans kan de ontwikkeling van een thema of plug-in op twee manieren beginnen:
Deze zijn niet inherent slecht, maar ik denk dat ze zwak zijn (en ik zal de eerste zijn om toe te geven dat ik beide meer heb gedaan dan ik zou willen delen!). Maar de stap "schrijfcode" veronderstelt veel, nietwaar??
Voor iedereen die al geruime tijd code schrijft, ben je maar al te bekend dat je op dat punt terechtkomt en beseft dat "Oh ... daar heb ik niet aan gedacht."
Als je geluk hebt, betekent dit meestal dat je een hulpmethode kunt schrijven of een andere voorwaardelijke om de zaak te behandelen die je hebt verwaarloosd, maar in het ergste geval betekent dit dat je misschien je hele klas of je hele set functies moet herwerken geschikt voor dit probleem.
Het testen van eenheden, hoewel niet perfect, kan dit helpen verzachten.
Overweeg het feit dat u vanaf het begin alle functies vermeldt die u met uw thema of plug-in wilt aanbieden. Je moet nog een willekeurige code schrijven, maar misschien heb je een soort schets van de gebruikersinterface en / of een reeks klassendiagrammen.
Vervolgens begin je de tests te schrijven die je gaat schrijven om je project te testen. Bedenk dat een deel van het testen van eenheden de code opsplitst naar de meest atomaire eenheid die mogelijk is, dus je bent belast met het schrijven van eenheidstesten voor elk van deze, ahum, units.
Vanwege de aard van het testen van eenheden, denk je inherent anders aan je code: in plaats van 'code schrijven', denk je aan 'schrijftests' en omdat je op een meer atomair niveau moet denken, kun je niet helpen, maar overweeg randgevallen die zo vaak in 'schrijfcode' worden gegroepeerd.
Als ontwikkelaars zijn we veel te comfortabel in het gebruik van conventies die voortdurend versterken dat we code schrijven. Daarmee bedoel ik dat we de neiging hebben om verkorte variabelenamen, cryptische functienamen en klassenamen aan te geven die voor niemand buiten jezelf of het team dat aan je project werkt iets betekenen..
Het testen van eenheden is niet noodzakelijkerwijs de sleutel tot het schrijven van code die gemakkelijker te lezen is, maar het kan een beetje verder gaan door te helpen schonere functienamen te bieden.
Denk aan het eerste programmeerboek dat je hebt gelezen, de eerste computerwetenschapsklasse die je hebt gevolgd, of het eerste stukje open-sourcecode dat je zag, de methode-namen zijn meestal werkwoorden. Waarom zouden ze dat niet zijn? Methoden zijn manieren om dat in te kapselen doet dingen. Maar naarmate we langer en langer aan projecten werken, worden we luier en luier en onze code gaat van "register_user_and_email_password ()" naar "nieuw account()".
Het eerste is uiteraard schoner dan het laatste, maar als we streven naar kwaliteitstesten en we willen ervoor zorgen dat onze unit-tests gemakkelijk te lezen zijn en zodat ze gemakkelijk leesbaar zijn, moeten onze functienamen makkelijk te lezen.
Is dit niet eenvoudiger te lezen:
$ this-> assertFalse (register_user_and_email_password (")); In plaats van dit?
$ this-> assertFalse (new_account (")); Nogmaals, misschien is dit een eenvoudig voorbeeld, maar het principe blijft: Goede eenheidstests schrijven om te helpen bij het zelfdocumenteren van de code die de taal van uw functies aandrijft.
We hebben het gehad over de basisprincipes van het testen van eenheden en de belangrijkste voordelen, maar we moeten de nadelen bespreken die gepaard gaan met het testen van eenheden en we hebben zelfs niet gekeken hoe we dit in onze werkstroom kunnen integreren..
Dus in het volgende artikel zullen we proberen dat te doen.
