Share
Vi har sett på enhetstesting for WordPress-utvikling. Gjennom bruk av praktiske eksempler har vi vurdert hva enhetstesting ser ut til både plugins og temaer; Vi har imidlertid ikke snakket om teorien bak enhetstesting.
Det vil si at vi ikke har tatt et høyt nivå på hva det er, hvorfor det er fordelaktig, og hvordan vi kan innlemme det i arbeidsflyten vår. I den neste serien av artikler skal vi definere enhetstesting, dekke de viktigste fordelene, hvorfor vi burde plage å gjøre det, og noen av ressursene som er tilgjengelige for oss å bruke i vårt arbeid.
Selv om det ikke er kode for å jobbe gjennom for denne spesielle opplæringen, bør den gi et solid grunnlag som den praktiske anvendelsen av de tidligere artiklene stole på.
Før du drar inn i artikkelen, tror jeg det er viktig å vurdere årsakene til at man bør plage å teste temaer og plugins i det hele tatt.
Frem til nylig har WordPress blitt sett hovedsakelig som en blogging-plattform og som et innholdsadministrasjonssystem. Det gjør begge disse veldig Vel, men som utviklere oppdager sin rike API, blir det mer populært å bygge visse typer applikasjoner ved hjelp av WordPress som den underliggende plattformen.
I tillegg er temaer mer enn skinn for et nettsted - de er mer enn et stilark og noen få malfiler for visning av data. Faktisk, nå, kanskje mer enn noensinne, har hele lagene dedikert tid (og til og med lever av) produserer temaer for WordPress. Så ikke la ordet "tema" misguide deg - temaer er som applikasjoner for WordPress. De legger til funksjonalitet, de forhåndsbehandler og etterprosesserer data, og presenterer ofte betydelig funksjonalitet i WordPress langt utover bare å gi nettstedet ditt en ansiktsløftning.
Til slutt er plugins nesten mer applikasjonslignende enn temaer. Tenk på det på denne måten: Plugins forlenge kjernen i WordPress og de jobber ofte uavhengig av temaer. I stedet legger de til helt nye funksjoner i kjernen i WordPress, som alle temaer kan ha nytte av.
Jeg sier alt dette for å gi noe perspektiv på hvorfor enhetstesting - som vi skal oppdage - kan betale mange ganger over gitt at den brukes i sammenheng med mer komplekse temaer og plugins.
Vi berørte oss kort i den første artikkelen i serien. Jeg vil ikke gi en total rehash av det som allerede er skrevet, så jeg oppsummerer punktene her:
Men det er bare å skrape overflaten.
For å virkelig forstå enhetene i temaet eller plugin-modulen, må du tenke på hva som komponerer et tema. Vanligvis er det en kombinasjon av:
Selv om det er enhetstestrammer spesifikt for JavaScript, skal vi fokusere mer på PHP-aspektet av WordPress-utviklingen. Tross alt, var det ikke for server-side funksjonalitet, ville det være svært lite unikt funksjonalitet introdusert i WordPress.
Med det sagt er det flere måter å definere en enhet på, men jeg vil satse på at folk flest definerer en enhet som en funksjon. For det meste er det riktig, men det betyr ikke at våre funksjoner er de mest optimale enhetene som skal testes. Funksjonene består for eksempel ofte av flere blokker - kanskje looper, kanskje betingelser, eller kanskje samtaler til andre funksjoner.
Uansett hva som er tilfelle, er det ofte mindre funksjonsfunksjoner som finnes i metoder.
Så er det virkelig nøyaktig å si at enhetstesting innebærer testing av hver funksjon som utgjør et tema? Ikke egentlig. Siden en enkelt blokk med kode - eller i enkelte tilfeller en enkelt setning - er ansvarlig for å oppnå en bestemt oppgave, disse ville utgjøre sanne kodenheter.
Og hvis vi skal skrive enhetstester, hvordan skriver vi tester for enhetene som finnes i våre funksjoner?
Husk det tidligere i serien, sa jeg:
Dette er hvor en av de største skiftene i skriftlig enhetstestbar kode oppstår: du bryter ut enheter av funksjonalitet til det minste atomare stykket mulig. Visst, dette resulterer ofte i et høyt antall svært små funksjoner, men er det en dårlig ting?
Ved å gjøre dette har hver funksjon virkelig et enkelt formål. Og forutsatt at funksjonen din gjør en ting, er det bare så mange måter å nevne funksjonen som til slutt kan resultere i mye mer lesbar kode.
Selvfølgelig er det en handel som du faktisk kan introdusere noen flere linjer med kode mens du skriver disse tilleggsfunksjonene, men når du jobber med et produkt med et lag av andre mennesker som vil bli brukt av tusenvis av kunder, du må spørre deg selv om tilleggskoden er verdt kvaliteten du kan få i riktig å teste arbeidet ditt. Gjort rett, laget ditt bør kunne lettere følge kodenes logikk og produktet vil ha et kvalitetsnivå som ofte er vanskelig å oppnå uten å skrive enhetstester.
En viktig ting å gjenkjenne om enhetstester er at de ikke er avhengige av hverandre. En enkelt enhetstest bør teste en og en ting. Videre betyr dette at en enhetstest egentlig bare bør inneholde en enkelt påstand (men det er unntak som er vist her).
Husk: Formålet med en enhetstest er å evaluere kvaliteten på en enkelt enhet av kode. Noen enheter vil akseptere argumenter, enkelte enheter vil ikke, noen enheter vil returnere verdier, andre vil ikke. Uansett hva som er tilfelle, bør enhetstestet evaluere alle tilfeller. En enkelt enhet av kode vil sjelden ha en enkelt test.
I stedet vil jeg si at en god tommelfingerregel er at antall tester assosiert med en enhet av kodeskala eksponentielt basert på antall innganger det aksepterer.
For eksempel:
Gir mening? Nøkkelen tar bort her er at du skal ha betydelig flere tester enn det er enheter; Det er ikke et forhold på 1: 1.
Til slutt, når du utfører enhetsprøving, vil du ofte se ordet "test suite" eller "suite" som brukes når du diskuterer testene. Dette kan variere basert på konteksten der testingen foregår; Men når du arbeider med WordPress, refererer dette vanligvis til en samling av enhetstester.
Så la oss si at du har en fil som er ansvarlig for å teste all funksjonalitet rundt å skrive og publisere et innlegg - denne filen vil være testpakken for innlegg. Enkelt nok, ikke sant? Det er viktig å forstå denne terminologien hvis du kommer over dette ved videre lesing, da det kan avvike noe hvis du jobber med, for eksempel Rails eller .NET.
Endelig er enhetstesting ikke en ny metodikk, og det er ikke strengt begrenset til PHP. Faktisk har enhetstesting (eller testdrevet utvikling som helhet) eksistert i godt over et tiår.
Du kan finne enhetstestingsrammer for Java, .NET, Rails, PHPUnit (åpenbart), og så videre.
Men adopsjonen er blandet - noen mennesker lever og dør av det, andre hater det, og da er det de som ønsker å begynne å gjøre det, men må balansere den praktiske anvendelsen av å bringe det inn i et eksisterende prosjekt og forstå de mengde refactoring dette kan kreve.
Når det gjelder teori er det bare å komme i gang.
I den neste artikkelen tar vi en titt på de viktigste fordelene ved enhetstesting og hvordan det kan lønne seg i vår WordPress-baserte utvikling. Vi vil også undersøke fordelene som enhetstesting bringer til arkitektur, design og dokumentasjon.
Selvfølgelig er enhetstesting ikke uten sine ulemper, så vi vil se på dem også.
Accentsconagua