Share
Vi har tittat på enhetstestning för WordPress-utveckling. Genom att använda praktiska exempel har vi granskat vilken enhetstest som ser ut för både plugins och teman; Vi har emellertid inte riktigt pratat om teorin bakom enhetstestning.
Det vill säga att vi inte har tittat på hög nivå på vad det är, varför det är fördelaktigt och hur vi kan införliva det i vårt arbetsflöde. I nästa serie artiklar kommer vi att definiera enhetsprovning, täcka dess viktigaste fördelar, varför vi borde bry sig om det och några av de resurser som finns tillgängliga för oss att använda i vårt arbete.
Även om det inte finns någon kod att arbeta för för denna speciella handledning, bör den ge en solid grund som den praktiska tillämpningen av tidigare artiklar bygger på.
Innan du dyker in i artikeln skulle jag tro att det är viktigt att överväga anledningarna till att man borde störa testning av teman och plugins alls.
Fram tills nyligen har WordPress setts främst som en bloggplattform och som ett innehållshanteringssystem. Det gör båda dessa mycket Tja, men som utvecklare upptäcker sitt rika API blir det allt populärare att bygga vissa typer av applikationer med WordPress som underliggande plattform.
Dessutom är teman mer än skinn för en webbplats - de är mer än ett stilark och några mallfiler för visning av data. Faktum är att nu, kanske mer än någonsin, hela teamet ägnar sig åt tid (och till och med lever av) att producera teman för WordPress. Låt inte ordet "tema" misguide dig - teman är som applikationer för WordPress. De lägger till funktionalitet, de förbehandlar och efterprocessar data, och presenterar ofta betydande funktionalitet i WordPress långt bortom att helt enkelt ge din webbplats en ansiktslyftning.
Slutligen är plugins nästan mer applikationslika i naturen än teman. Tänk på det här sättet: plugins utökar kärnan i WordPress och de arbetar ofta oberoende av teman. I stället lägger de till helt nya funktioner i kärnan i WordPress, från vilken alla teman kan gynna.
Jag säger allt detta för att ge ett visst perspektiv på varför enhetstestning - som vi håller på att upptäcka - kan betala många gånger över givet att den används i samband med mer komplexa teman och plugins.
Vi berörde kort detta i den första artikeln i serien. Jag vill inte ge en total rehash av vad som redan har skrivits, så jag sammanfattar punkterna här:
Men det är bara att skrapa ytan.
För att verkligen förstå enheterna i ditt tema eller plugin måste du tänka på vad som komponerar ett tema. Det är vanligtvis en kombination av:
Även om det finns enhetstestramar specifikt för JavaScript, kommer vi att fokusera mer på PHP-aspekten av WordPress-utveckling. Om det inte var för serverfunktionens funktionalitet, skulle det vara mycket lite unikt funktionalitet som introducerades i WordPress.
Med det sagt finns det flera sätt att definiera en enhet men jag skulle satsa på att de flesta människor definierar en enhet som en funktion. För det mesta är det bra, men det betyder inte att våra funktioner är de mest optimala enheterna att testa. Funktioner består till exempel av flera block - kanske loopar, kanske villkor, eller kanske samtal till andra funktioner.
Oavsett fallet finns det ofta mindre funktionsenheter som ingår i metoderna.
Så är det verkligen korrekt att säga att enhetsprovning innebär att testa varje funktion som utgör ett tema? Inte riktigt. Eftersom ett enda block av kod - eller i vissa fall en enda uppsats - är ansvarig för att uppnå en specifik uppgift, dessa skulle utgöra sanna enheter av kod.
Och om vi ska skriva enhetstester, hur skriver vi test för enheterna som finns inom våra funktioner?
Minns det tidigare i serien, sa jag:
Det här är en av de största skiftningarna i skrivbar enhetstestbar kod: du bryter ut enheter av funktionalitet till den minsta atomdelen som möjligt. Visst, detta resulterar ofta i ett stort antal mycket små funktioner, men det är en dålig sak?
Genom att göra detta har varje funktion verkligen ett enda syfte. Och förutsatt att din funktion gör en enda sak, det finns bara så många sätt att namnge funktionen som till sist kan resultera i mycket mer läsbar kod.
Självklart finns det en avvägning eftersom du faktiskt kan introducera några fler kodrader medan du skriver dessa ytterligare funktioner, men när du arbetar på en produkt med ett team av andra människor som kommer att användas av tusentals kunder, du måste fråga dig själv om tilläggskoden är värt den kvalitet du kan få för att testa ditt arbete korrekt. Gör rätt, ditt lag skall kunna lättare följa kodens logik och produkten kommer att ha en kvalitetsnivå som ofta är svår att uppnå utan att skriva enhetstester.
En viktig sak att känna igen om enhetsprov är att de inte är beroende av varandra. Ett enda test ska testa en och en sak. Vidare betyder det att ett enhetstest verkligen bara bör innehålla en enda påstående (men det finns undantag som visas här).
Kom ihåg: Syftet med ett enhetstest är att utvärdera kvaliteten på en enda kodens enhet. Vissa enheter accepterar argument, vissa enheter kommer inte, vissa enheter returnerar värden, andra kommer inte. Vad som än är fallet ska ditt prov på enheten utvärdera alla fall. En enda kodkod kommer sällan att ha ett enda test.
Istället skulle jag säga att en bra tumregel är att antalet test som hör samman med en enhet av kodskalor exponentiellt baserat på antalet ingångar som den accepterar.
Till exempel:
Vettigt? Nyckeln ta bort här är att du kommer att ha betydligt fler test än det finns enheter; Det finns inte ett 1: 1-förhållande.
Slutligen, när du utför enhetstestning, ser du ofta ordet "test suite" eller "suite" som används vid diskussion av testen. Detta kan variera beroende på det sammanhang där testningen sker. Men när man arbetar med WordPress, refererar det vanligen till en samling av enhetstester.
Så låt oss säga att du har en fil som ansvarar för att testa all funktionalitet kring att skriva och publicera ett inlägg - den här filen skulle vara testpaketet för inlägg. Lätt nog, eller hur? Det är viktigt att förstå denna terminologi om du kommer över det här i ytterligare läsning, eftersom det kan skilja sig något om du arbetar i, säger Rails eller .NET.
Slutligen är enhetstestning inte en ny metod och det är inte strängt begränsat till PHP. Faktum är att enhetstestning (eller testdriven utveckling som helhet) har funnits i drygt ett decennium.
Du kan hitta enhetstestning ramar för Java,. NET, Rails, PHPUnit (självklart), och så vidare.
Men dess antagande har blivit blandad - vissa människor bor och dör av det, andra hatar det och då finns det de som vill börja göra det, men måste balansera den praktiska tillämpningen av att föra den till ett befintligt projekt och förstå mängd refactoring som detta kan kräva.
När det gäller teorin är vi bara igång.
I nästa artikel kommer vi att titta specifikt på de viktigaste fördelarna med enhetstestning och hur det kan löna sig i vår WordPress-baserade utveckling. Vi ska också undersöka de fördelar som enhetstestning ger till arkitektur, design och dokumentation.
Enhetsprovning är naturligtvis inte utan dess nackdelar, så vi tittar också på dem.
Accentsconagua