Share
In de afgelopen twee artikelen hebben we de theorie van het testen van eenheden eens onder de loep genomen en kunnen we ons helpen bij de ontwikkeling van WordPress. We hebben het testen van eenheden gedefinieerd en verschillende manieren onderzocht die het ons tijdens onze projecten kan helpen.
Maar we hebben nog meer te dekken.
In dit laatste artikel zullen we bekijken waarom we de moeite moeten nemen om unit tests uit te voeren en we zullen de voor- en nadelen van het doen samenvatten. Vervolgens bekijken we hoe we testen kunnen retrofitten in onze bestaande projecten. En om het af te ronden, zullen we een lijst samenvatten van bronnen die specifiek voor ons beschikbaar zijn WordPress-ontwikkelaars die zullen helpen om onze thema's te testen.
Het overkoepelende thema van deze hele serie ging over waarom we ons zouden moeten bezighouden met het testen van eenheden, maar als dit niet bondig is vermeld, is dit de reden waarom:
Unit Testing helpt ons om problemen vroegtijdig te ontdekken, ontwikkelaars een niveau van zelfdocumenterende code te bieden en geeft ons een hogere kwaliteit software.
Toegegeven, dit veronderstelt dat we doorgaan met het oefenen van goede eenheidstesttechnieken. Natuurlijk was dit uitgebreid behandeld in het vorige artikel, maar het is de moeite waard om te herhalen.
Een belangrijk ding om op te merken - vooral als je dit probeert toe te passen in een meer zakelijke omgeving of in de context van een grotere onderneming - is dat het testen van eenheden niet iets is dat ontwikkelaars voor zichzelf doen. Kwaliteit is tweezijdig - het komt de klant ten goede en het komt het bedrijf ten goede.
Door een hoger kwaliteitsniveau voor de klant te bieden - dat wil zeggen, grondiger geteste software - zouden ze minder fouten moeten ervaren. Omdat fouten tijd opleveren die ontwikkelaars moeten uitgeven in plaats van te werken aan nieuwe projecten of nieuwe functies van bestaande producten, kan dit uiteindelijk geld besparen.
Door een hoger kwaliteitsniveau voor het bedrijf te bieden, hebben ontwikkelaars meer vertrouwen in hun inspanningen omdat ze een reeks tests kunnen uitvoeren telkens wanneer een wijziging wordt doorgevoerd, wetende hoe hun werk de hele applicatie beïnvloedde. Als een test mislukt, kunnen ze deze oplossen voordat ze worden geïmplementeerd voor productie.
Unit Testing gaat over kwaliteit en het beïnvloedt niet alleen degenen die de code schrijven, maar ook het bedrijf dat het verzendt, en de klanten die het gebruiken.
De waarheid is dat we al de voordelen van unit-testen hebben besproken. Voor de volledigheid, laten we ze hier samenvatten (hoewel je ze altijd in detail kunt bekijken!). Testen van een eenheid…
Alles klinkt geweldig, toch? En ja, het is gebaseerd op ontwikkelaars die zichzelf verantwoordelijk houden voor hoge normen en praktijken als het gaat om het daadwerkelijk implementeren in het dagelijkse werk, maar het testen van eenheden is niet zonder nadelen.
Dit is al in deze serie gezegd: unit testing kost veel tijd. Toegegeven, als u met een nieuw project begint, is de tijdsinvestering veel lager dan als u dit in een bestaande toepassing past, maar u bent nog steeds meer code moeten schrijven dan zonder testen.
Omdat je meer code schrijft, neem je meer tijd - opnieuw aan de voorkant van het project. De voordelen van het testen van eenheden komen vaak pas later, maar als een project een specifieke streefdatum voor vrijgave heeft en die release een bepaald aantal functies bevat, is het niet waarschijnlijk dat u alle eenheidstests en de functies in de vrijlating.
Als u kleinere functiesets wilt vermijden bij het vrijgeven of vertragen van streefdata, u hebben op tijd bouwen voor unit testing.
Je hebt ze allemaal gehoord: complexiteit doodt, houdt het simpel dom, minder is meer, enzovoort.
Eerlijk gezegd, al deze zijn waar en ze hebben hun juiste plaats in ontwikkeling, maar het feit is dat het testen van eenheden is aanvullende code en aanvullende code altijd introduceert meer complexiteit. Daarom moeten we ervoor zorgen dat we een deugdelijke manier hebben om al onze unit-tests te beheren en te organiseren.
Misschien is het de bestandsorganisatie, naamafstand, naamgevingsconventies, of versies van versies, of al het bovenstaande. Wat het ook is dat je uiteindelijk doet, unit tests mogen niet worden behandeld als tweederangsburgers in de wereld van software - ze moeten zoveel mogelijk worden onderworpen aan dezelfde ontwerpprincipes als andere klassen of functies..
Jazeker, in het vorige artikel hebben we gezegd dat unit testing het ontwerp van een applicatie kan helpen aandrijven en het kan helpen bij het bevorderen van een ontwerp dat de hele applicatie meer testbaar maakt. Dit klopt nog steeds, maar dit gaat ten koste van: soms is het ontwerp met de meeste testbare eenheden niet het duidelijkst.
Daarmee bedoel ik dat omdat een reeks functies - of zelfs een klasse - volledig eenheidsgetest is, de cohesie potentieel kan worden aangetast omdat we offers brengen voor toegang tot bepaalde functies om hun verwerking van gegevens te verifiëren. Natuurlijk is dit geen vaste regel en dit is misschien niet eens een probleem voor sommigen, maar je moet beslissen waar je dogmatisch over gaat zijn: is het een perfect samengestelde set van klassen en of functies of een aaneengesloten systeem van tests en functies die samenwerken?
Uiteindelijk denk ik dat het komt met hoe je tests ziet als een groter deel van het geheel. Als ze deel uitmaken van het ontwerp van uw toepassing, kan het ontwerp er niet onder lijden. Maar als u tests als een bijzaak bekijkt, kan het ontwerp van de kernapplicatie net iets worden aangetast.
Zoals ze zeggen, is software nooit gedaan en omdat unit testen deel uitmaakt van een stukje software, is het nooit gedaan.
Omdat een toepassing altijd in ontwikkeling zal zijn, of het nu bugs zijn die worden platgedrukt, nieuwe functies worden geïntroduceerd (of zelfs worden verwijderd), de bijbehorende tests moeten ook worden toegevoegd of bijgewerkt. En het komt altijd terug in de tijd.
Bovendien, als u in een team van ontwikkelaars werkt, kan ons gebrek aan updatetests een negatieve invloed hebben op het team, omdat de resultaten die het testrapport mogelijk onjuiste of foutieve negatieven kunnen zijn. Zodra tests zijn geschreven, is het noodzakelijk dat ze worden bijgewerkt; anders kunnen ze resulteren in een zeer slecht product.
Eenheidstesten is een stuk gemakkelijker te verkopen wanneer u met een project begint, maar als u op zoek bent om het achteraf in een bestaande toepassing (of thema of plug-in, in ons geval) aan te passen, zal het een beetje tijd kosten en inspanning.
En hoewel er geen wonder is voor hoe je dit perfect kunt uitvoeren, zijn er een paar goede manieren om de praktijk in je dagelijkse werk te implementeren:
Als u de bovenstaande stappen volgt, krijgt u uiteindelijk een aanzienlijke hoeveelheid codedekking. Ja, het kost tijd en ja u zult waarschijnlijk veel van de code moeten herwerken, maar diezelfde investering zal ook in de toekomst van uw product winst opleveren.
Hier is een samenvatting van de bronnen die kunnen bijdragen aan het succesvol testen van uw WordPress-projecten:
Tussen de eerste serie artikelen en deze reeks artikelen is een stevige basis gelegd waarop u uw unit-testmethoden kunt blijven ontwikkelen.
Accentsconagua