Share
I de to siste artiklene har vi tatt en nærmere titt på teorien bak enhetstesting og hvordan den kan hjelpe oss i vår WordPress-utviklingsarbeid. Vi har definert enhetstesting og undersøkt ulike måter det kan hjelpe oss gjennom våre prosjekter.
Men vi har fortsatt mer å dekke.
I denne siste artikkelen vil vi se på hvorfor vi bør plage å gjøre enhetstesting, og vi vil oppsummere fordelene og ulempene ved å gjøre det. Deretter ser vi på hvordan vi kan etterfeste testing i våre eksisterende prosjekter. Og for å pakke opp, vil vi oppsummere en liste over ressurser som er tilgjengelige spesielt for oss WordPress-utviklere som vil hjelpe deg med å begynne å teste våre temaer.
Det overordnede temaet i hele denne serien har vært om hvorfor vi burde plage oss med enhetstesting, men hvis det ikke har blitt kortfattet oppgitt, er det derfor:
Enhetstesting hjelper oss med å avdekke problemer tidlig, gi utviklere et nivå av selvdokumenterende kode og gir oss et høyere kvalitetsnivå for programvare.
Gitt, dette antar at vi følger gjennom på å praktisere gode testteknikker. Selvfølgelig var dette dekket i detalj i den forrige artikkelen, men det er verdt å gjenta.
En viktig ting å merke seg - spesielt hvis du prøver å bruke dette i en mer bedriftskonfigurasjon eller i sammenheng med en større bedrift - er at enhetstesting ikke bare er noe utviklere gjør for seg selv. Kvalitet er tosidig - det fordeler kunden, og det fordeler virksomheten.
Ved å gi et høyere kvalitetsnivå for kunden - det vil si mer grundig testet programvare - de burde oppleve færre feil. Siden feil resulterer i at utviklere må bruke løsningen i stedet for å jobbe med nye prosjekter eller nye funksjoner i eksisterende produkter, kan dette til slutt spare penger.
Ved å gi et høyere kvalitetsnivå for virksomheten, er utviklere mer selvsikker i deres anstrengelser fordi de kan utføre en prøvepakke hver gang en endring er gjort, og vet hvordan deres arbeid påvirket hele applikasjonen. Hvis en test mislykkes, er de i stand til å løse det før de distribueres til produksjon.
Enhetstesting handler om kvalitet, og det påvirker ikke bare de som skriver koden, men virksomheten som sender den, og kundene som bruker den, også.
Sannheten er at vi allerede har dekket fordelene ved enhetstesting. For fullstendighet, la oss oppsummere dem her (selv om du alltid kan se gjennom dem i detalj!). Enhetstesting ...
Alt høres bra ut, ikke sant? Og ja, det er basert på utviklere som holder seg ansvarlig overfor høye standarder og praksis når det gjelder å faktisk implementere dette i det daglige arbeidet, men enhetstesting er ikke uten sine ulemper.
Dette har blitt sagt gjennom hele denne serien: enhetstesting tar en betydelig investeringstid. Ganske vist, hvis du starter et nytt prosjekt, er investeringen i tiden mye lavere enn om du tilpasser dette til et eksisterende program, men du er fortsatt å skrive mer kode enn uten testing.
Fordi du skriver mer kode, tar du mer tid - igjen, på forsiden av prosjektet. Fordelene ved enhetstesting kommer ofte ikke til senere, men hvis et prosjekt har en bestemt måldato for utgivelse, og at utgivelsen inneholder et visst antall funksjoner, er det ikke sannsynlig at du passer alle enhetstester og funksjonene inn i utgivelsen.
Hvis du vil unngå mindre funksjonssett ved utgivelse eller forsinkede måldatoer, vil du ha å bygge opp tid for enhetstesting.
Du har hørt dem alle: Kompleksitet dreper, holder det enkelt dumt, mindre er mer, og så videre.
Ærlig, alle disse er sanne og de har sitt rette sted i utvikling, men faktum er at enhetstesting er tilleggskode og tilleggskode alltid introduserer mer kompleksitet. Som sådan må vi sørge for at vi har en riktig måte å håndtere og organisere alle våre enhetstester på.
Kanskje det er filorganisasjon, navnavstand, navnekonvensjoner eller versjoner eller alle de ovennevnte. Uansett hva det er som du ender med, bør enhetstester ikke bli behandlet som førsteklasses borgere i programvareverdenen - de bør være underlagt de samme designprinsippene som andre klasser eller funksjoner så mye som mulig.
Ja, i den siste artikkelen sa vi at enhetstesting kan hjelpe til med å drive utformingen av et program, og det kan bidra til å fremme et design som gjør hele applikasjonen mer testbar. Dette er fortsatt sant, men det kommer på bekostning: noen ganger er den mest enhetlige testbare designen ikke den klareste.
Dermed mener jeg at fordi et sett med funksjoner - eller til og med en klasse - er helt enhetstestet, har samholdet potensialet til å bli kompromittert fordi vi gjør ofre for å få tilgang til visse funksjoner for å verifisere databehandlingen av data. Selvfølgelig er dette ikke en vanskelig og rask regel, og dette kan ikke engang være et problem for noen, men du må bestemme hva du skal være dogmatisk om: er det et perfekt utformet sett med klasser og eller funksjoner eller et sammenhengende system av tester og funksjoner som fungerer sammen?
Til syvende og sist tror jeg at det kommer ned på hvordan du ser tester som en stor del av det hele. Hvis de er en del av søknadens design, kan designet ikke lide. Men hvis du ser på tester som en ettertanke, kan utformingen av kjerneprogrammet bli kompromittert bare litt.
Som de sier, er det aldri gjort programvare, og siden enhetstesting er en del av et program, blir det aldri gjort.
Fordi en applikasjon alltid skal utvikle seg - det være seg at bugs blir squashed, nye funksjoner blir introdusert (eller til og med fjernet), de tilhørende testene må også legges til eller oppdateres. Og det kommer alltid tilbake til tiden.
Videre, hvis du jobber i et team av utviklere, kan vår mangel på oppdateringstester negativt påvirke teamet da resultatene som tester rapporterer kan være falske positive eller falske negativer. Når testene er skrevet, er det viktig at de oppdateres. ellers kan de resultere i et svært dårlig produkt.
Enhetstesting er mye lettere å selge når du starter med et prosjekt, men hvis du ønsker å omforme det til et eksisterende program (eller tema eller plugin, i vårt tilfelle), vil det ta litt tid og anstrengelse.
Og selv om det ikke er noen sølvkule for hvordan du perfekt kan utføre dette, er det noen gode måter å begynne å implementere øvelsen på i ditt daglige arbeid:
Hvis du følger trinnene ovenfor, vil du til slutt ende opp med en betydelig mengde kodetekning. Ja, det tar tid og ja, du må sannsynligvis tilpasse mye av koden, men samtidig vil investeringen gi utbytte i fremtiden for produktet ditt.
Her er et sammendrag av ressursene som kan bidra til vellykket testing av dine WordPress-baserte prosjekter:
Mellom den første serien av artikler og denne artikkelen er det lagt et sterkt fundament som du kan fortsette å bygge enhetens testing praksis på..
Accentsconagua