Share
Under de senaste två artiklarna har vi tittat på teorin bakom enhetstestning och hur det kan hjälpa oss i vår WordPress-utvecklingsinsats. Vi har definierat enhetstestning och granskat olika sätt att det kan hjälpa oss genom hela våra projekt.
Men vi har fortfarande mer att täcka.
I den här sista artikeln kommer vi att granska varför vi ens borde störa enhetstestning och vi sammanfattar fördelarna och nackdelarna med att göra det. Därefter tittar vi på hur vi kan ompröva testningen i våra befintliga projekt. Och för att paketera upp, sammanfattar vi en lista med resurser som är tillgängliga specifikt för oss WordPress-utvecklare som kommer att hjälpa till att börja testa våra teman.
Det övergripande temat för hela serien har handlat om varför vi borde störa enhetstestning, men om det inte har varit kortfattat sagt, är det därför:
Enhetstestning hjälper oss att upptäcka problem tidigt, ge utvecklare en nivå av självdokumentationskod och ger oss en högre kvalitet på programvara.
Beviljas, förutsätter detta att vi följer igenom på att utöva goda testtekniker. Det här förstod naturligtvis i detalj i den föregående artikeln, men det är värt att upprepa.
En viktig sak att notera - speciellt om du försöker tillämpa detta i en mer företagsinställning eller i samband med ett större företag - är det att testning av enheter inte bara är något som utvecklare gör för sig själva. Kvaliteten är dubbelsidig - det gynnar kunden och det gynnar verksamheten.
Genom att tillhandahålla en högre kvalitetsnivå för kunden, det vill säga mer noggrant testad programvara, borde de uppleva färre buggar. Eftersom buggar resulterar i att utvecklare måste spendera lösningar i stället för att arbeta på nya projekt eller nya funktioner hos befintliga produkter, kan detta i slutändan spara pengar.
Genom att ge en högre kvalitetsnivå för verksamheten är utvecklare säkrare i sina ansträngningar eftersom de kan genomföra en testpaket varje gång en förändring görs och att veta hur deras arbete påverkar hela applikationen. Om ett test misslyckas, kan de lösa det innan de distribueras till produktion.
Enhetstester handlar om kvalitet och det påverkar inte bara de som skriver koden, men det företag som levererar det och de kunder som använder det också.
Sanningen är att vi redan har täckt fördelarna med enhetstestning. För fullständighet, låt oss sammanfatta dem här (även om du alltid kan granska dem i detalj!). Enhetstestning ...
Alla låter bra, eller hur? Och ja, det beror på att utvecklare håller sig ansvariga för höga standarder och praxis när det gäller att faktiskt genomföra detta i det dagliga arbetet, men testning av enheten är inte utan dess nackdelar.
Detta har sagts i hela serien: enhetsprovning tar en betydande tid investering. Visserligen, om du startar ett nytt projekt är tidsinvesteringen mycket lägre än om du anpassar detta till en befintlig applikation, men du är fortfarande måste skriva mer kod än utan testning.
Eftersom du skriver mer kod tar du mer tid - igen, på projektets främre del. Fördelarna med enhetstestning kommer ofta inte förrän senare, men om ett projekt har ett specifikt måldatum för utgåva och den här utgåvan innehåller ett visst antal funktioner är det inte troligt att du passar alla enhetstest och funktionerna i frisättningen.
Om du vill undvika mindre funktionssätt vid släpp eller fördröjda måldatum, ska du ha att bygga in tid för enhetstestning.
Du har hört dem alla: komplexitet dödar, håll det enkelt dumt, mindre är mer och så vidare.
Ärligt talat är alla dessa sanna och de har sin rätta plats i utveckling, men faktum är att enhetsprovning är ytterligare kod och tilläggskod alltid introducerar mer komplexitet. Som sådan måste vi se till att vi har ett ordentligt sätt att hantera och organisera alla våra testsatser.
Kanske är det filorganisation eller namnavstånd, eller namngivningskonventioner, eller versionsversioner eller alla ovanstående. Oavsett det du slutar göra, bör enhetstester inte behandlas som andraklassiga medborgare i mjukvarans värld - de bör omfattas av samma designprinciper som andra klasser eller funktioner så mycket som möjligt.
Ja, i den senaste artikeln sa vi att enhetstestning kan hjälpa till att driva utformningen av en applikation och det kan hjälpa till att skapa en design som gör hela applikationen mer testbar. Detta är fortfarande sant, men det kommer på bekostnad: ibland är den mest enhetliga testbara designen inte den klaraste.
Därför menar jag att eftersom en uppsättning funktioner - eller till och med en klass - är helt testad, kan sammanhållningen komma att äventyras, eftersom vi gör offer för att få tillgång till vissa funktioner för att verifiera deras behandling av data. Det här är självklart inte en hård och snabb regel, och det kan inte ens vara ett problem för någon, men du måste bestämma vad du ska vara dogmatisk om: är det en perfekt konstruerad uppsättning klasser och eller funktioner eller ett sammanhängande system av test och funktioner som fungerar tillsammans?
I slutändan tror jag att det kommer ner på hur du ser test som en större del av det hela. Om de ingår i din ansökans design, kan det hända att designen inte lider. Men om du tittar på tester som en eftertanke, kan designen av kärnanvändningen äventyras bara lite.
Som de säger är programvara aldrig gjort och eftersom enhetstestning är en del av ett program, är det aldrig gjort.
Eftersom en applikation alltid kommer att utvecklas - oavsett om det är buggar som är squashed, nya funktioner introduceras (eller till och med borttagna), kommer de associerade testen att behöva läggas till eller uppdateras också. Och det kommer alltid tillbaka till tiden.
Om du arbetar i ett team av utvecklare kan vår brist på uppdateringstest negativt påverka laget eftersom resultaten som testrapporten kan vara falska positiva eller falska negativa. När test har skrivits är det absolut nödvändigt att de uppdateras. annars kan de resultera i en mycket dålig produkt.
Enhetstestning är mycket enklare att sälja när du börjar med ett projekt, men om du vill omforma det till en befintlig applikation (eller tema eller plugin, i vårt fall), kommer det att ta lite tid och ansträngning.
Och även om det inte finns något silverkula för hur du perfekt kan genomföra det här, finns det några bra sätt att börja genomföra praktiken i ditt dagliga arbete:
Om du följer ovanstående steg kommer du slutligen att sluta med en betydande mängd koddekning. Ja, det tar tid och ja du kommer sannolikt att behöva omarbeta en hel del koden, men så mycket kommer investeringen att ge utdelning i framtiden för din produkt.
Här är en sammanfattning av resurserna som kan bidra till framgångsrik testning av dina WordPress-baserade projekt:
Mellan den första serien av artiklar och denna serie artiklar har en stark grund lagts på som du kan fortsätta bygga din testningspraxis för enhet.
Accentsconagua