Mikä on yksikkötestaus?
Yksikkötestaus on itsestään selvä sana, jos ymmärretään mitä yksiköllä tarkoitetaan. Yksikkö on pienin mahdollinen koodi, joka voidaan loogisesti eristää järjestelmästä. Tämä tarkoittaa, että mitä tahansa koodipalaa, joka voi ottaa syötteitä, suorittaa tehtävän ja tuottaa ulostulon, vaikka se olisi riippumaton koko järjestelmästä tai ratkaisusta, voidaan kutsua yksiköksi. Tämän koodikappaleen testaamista odotetun ulostulon generoimiseksi tietyllä sisääntulosarjalla kutsutaan yksikkötestaukseksi.
Yksikkötestauksen tyypit
Keskustelemme joistakin yksikkötestauksen tyypeistä.
1) Manuaalinen testaus
Koodin manuaalinen testaaminen edellyttää, että kehittäjä debugoi koodin jokaisen rivin manuaalisesti ja testaa sen tarkkuuden. Se voi vaatia myös askel askeleelta ohjeet, jos toiminnallisuus on monimutkainen.
2) Automaattinen testaus
Automaatiotestauksessa kehittäjä kirjoittaa koodin testikoodiksi. Tätä tuetaan yleensä yksikkötestauskehyksillä, joita ei käytetä tuotannossa. Muutoin kehittäjä voi halutessaan kirjoittaa testikoodin ilman kehystä ja kommentoida sitä manuaalisesti ennen käyttöönottoa.
Manuaalinen testaus näyttää ilmeisesti vievän aikaa useimmissa tapauksissa. Mutta joissakin tapauksissa, kun automaattisen testitapauksen kirjoittaminen kunkin skenaarion kattamiseksi ei ole mahdollista, manuaali on usein suositeltava menetelmä.
Miksi yksikkötestaus on tärkeää?
Yksikkötestauksen merkityksen ymmärtämiseksi meidän on tarkasteltava laajempaa kuvaa. Se on osa ohjelmistokehityksen elinkaarta. Katsokaamme lyhyesti muut osat saadaksesi paremman käsityksen yksikkötestauksen roolista.
Yllä oleva kuva on yksinkertainen esimerkki normaalista ohjelmistokehityksen elinkaaresta ja siihen liittyvistä testausprosesseista. Sanomattakin on selvää, että projektiprosessista riippuen koko prosessi vaihtelee tiettyjen komponenttien lisäämisen ja poistamisen kanssa. Testausprosessi kattaa kuitenkin ehdottomasti neljä tyyppiä, kuten alla kuvataan:
- Yksikkötestaus - Koko testausprosessin perustaso. Tämän suorittaa komponentin kehittäjä tai mikä tahansa hänen ikäisensä. Jälkimmäisessä tapauksessa sitä kutsutaan ohjelmistomaailmassa usein vertaistestaukseksi.
- Integrointitestaus - yksikkökomponentin testaaminen välittömällä vanhemmilla. Tavoitteena on tarkistaa, onko yksikkökomponentti hyvin integroitumassa muihin komponentteihin eikä se ole aiheuttanut minkään muun komponentin toimintahäiriöitä.
- Järjestelmätestaus - Koko järjestelmän testaaminen, kun yksikkökomponentti on asetettu paikoilleen.
- Hyväksyntätestaus - yleensä yrityksen / asiakkaan suorittama, se tarkistaa, vastaako lopputulos loppukäyttäjän odottamia toimintoja.
Siten voidaan hyvin nähdä, että kaikki testausprosessit luottavat testauksen perustasoon. Jos testausta ei suoriteta perustasolla, kaikki muut testit voivat johtaa turhaan.
Oletetaan nyt, että sinulla on koodi, jossa on kaksi osaa
- Laske korko.
- Lisää korko pääoman määrään ja laske etuuskorko.
Oletetaan, että et testannut yksikköä näistä komponenteista ja siirryt suoraan järjestelmän testaukseen. Järjestelmätestauksessa ilmenee virhe, että maturiteetti on virheellinen. Nyt missä koodin osassa on virhe?
- Se voi olla koronlaskennassa.
- Se voi olla yhdistämislogiikan soveltamisessa.
- Se voi olla koron lisäksi pääoman määrään.
Katso, kuinka se lisää työtä nyt. Kaikki tämä olisi voitu välttää, jos molemmat koodikomponentit olisi testattu yksiköillä.
Miksi yksikkötestaus on tärkeää?
- Se korjaa virheet vain kehitysvaiheessa. Tämä säästää paljon aikaa, vaivaa ja kustannuksia. Kuvittele, jos yksikkötestejä ei suoritettaisi, koodi menisi laadunvarmistustiimille ja lähettäisi sitä erittäin yksinkertaisten asioiden vuoksi.
- Hyvät yksikkötestit palvelevat myös yksityiskohtaisen dokumentoinnin tarkoitusta. Kun kehittäjä kirjoittaa yksikkötestauksia, hän kirjoittaa vahingossa koodin odotettavissa olevan toiminnallisuuden. Tämä ei ole mitään muuta kuin dokumentaatio, joka selittää koodin toiminnan.
- Sen avulla on helppo muokata ja ylläpitää koodia. Kun olet tehnyt muutoksia koodiin, suorita testit uudelleen ja viola, kaikki viat korjataan vaivattomasti.
- Se myös varmistaa modulaarisuuden. Yksikkötestejä suoritetaan yksittäisillä komponenteilla, mikä tarkoittaa, että koodin on oltava mahdollisimman rakeinen. Tämä varmistaa, että koodi on jaettu asianmukaisesti moduuleihin.
Mitalin toinen puoli
Sillä on myös joitain haittoja. Vaikka edut painavat haittapuolia ja koodin testaaminen on aina suositeltavaa, on silti järkevää tietää saman kolikon molemmat puolet.
- Yksikkötestaus, joka on aina niin perusteellinen, voi joskus epäonnistua myös kaikkien triviaalisen koodin virheiden löytämisessä. Kaikkia suorituspolkuja ei yksinkertaisesti ole mahdollista arvioida. Siksi yksikkötestit ovat usein suoraviivaisia onnellinen polku ja negatiivisia skenaarioita.
- Se vaatii kehittäjää ajattelemaan laatikosta ja yrittämään rikkoa koodinsa. Tämä on usein vaikeaa, koska kehittäjän käsitys painotetaan koodiin.
Yksikkötestaustyökalut
Alalla on useita työkaluja, jotka auttavat automatisoiduissa yksikkötestaustapauksissa. Kuten tarkoituksena on, ne helpottavat yksikkötestien kirjoittamista ja toteuttamista kehittäjälle. Kehittäjien maksettaessa on olemassa yksikkötestauskehysten maailma. Jotkut suosituimmista ja yleisimmin käytetyistä työkaluista on lueteltu alla.
JUnit
JUnit on ilmainen Java-testaustyökalu. Se sisältyy automaattisesti moniin projektimalleihin, jotka on saatavana erilaisten IDE: ien kanssa Java-kehitykseen. JUnit tekee erityisen se, että se testaa tiedot ensin ja testaa sitten koodin sen jälkeen, kun tiedot on lisätty siihen. Se tarjoaa myös väitteitä testimenetelmien tunnistamiseksi.
nunit
NUnit on .Net kuten JUnit on Java. Sillä on kaikki JUnit-sovelluksen tärkeimmät ominaisuudet, mutta .Net-ohjelmointikielen kehittämiseen. Se tukee myös testien suorittamista rinnakkain.
PHPUnit
Samoin kuin JUnit ja NUnit, PHPUnit on työkalu PHP-kehittäjille. Se tukee myös hyvän testaustyökalun kaikkia perusominaisuuksia.
xUnit
Toinen kehys, joka on yleisempi kuin vastaavat, on XUnit. Se tukee useita kieliä, kuten C ++, C #, ASP.Net jne. Se tarjoaa myös samanlaisia ominaisuuksia kuin muut markkinoilla olevat työkalut.
Jtest
Parasoft Jtest on kolmannen osapuolen laajennus, joka hyödyntää avoimen lähdekoodin kehyksiä, kuten JUnit, ja lisää yhden napsautuksen ratkaisut elämän helpottamiseksi. Jtest-sovelluksella voit luoda testikoodeja koodillesi automaattisesti vain muutamalla napsautuksella. Automatisoimalla nämä tehtävät kehittäjä voi vapaasti työskennellä testitapausten liiketoimintalogiikan kanssa.
QUnit
Erittäin suosittu JavaScript-yksikön testausjärjestelmä. Se voi testata JavaScript-koodia sekä asiakkaan että palvelimen puolella.
Jasmiini
Toinen erittäin laajalti käytetty testityökalu JavaScript-kehyksiin. Sillä on suuri yhteisön tuki Angularille, Reactille jne.
JMockIt
JMockIt on avoimen lähdekoodin työkalu, joka tukee myös API-puhelujen pilkkaamista tallennus- ja vahvistussyntaksin avulla.
Yksikkötestausesimerkki
Jokaisen yksikkötestauksen erittäin perusedellytys on testattava koodi. Oletetaan, että meillä on toiminto, joka tarkistaa onko puhelinnumerot oikeat (muodossa) vai eivät. Tämä kriteeri voi myös vaihdella maantieteellisestä sijainnista riippuen. Joten emme korosta kriteerejä. Keskitymme pikemminkin yksikkötestaukseen.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Nyt meidän on testattava tämä koodi.
Voimme joko testata sen manuaalisesti lisäämällä erilaisia arvoja ja tarkistamalla tulosteen. Tämä voi tuntua helpoalta ensimmäisellä katselulla, mutta on toistuva tehtävä, jos koodiin tehdään muutoksia.
Vaihtoehtoisesti voimme kirjoittaa yksikkötestauksen, joka voi toimia validoijana niin kauan kuin liiketoimintalogiikka pysyy samana. Yksikkötesti ei muutu, vaikka vaihtaisimme koodia. Joten kirjoitetaan yksikkötestaus edellä mainitulle koodille.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
Joten miten yllä oleva yksikkötestikoodi toimii? Huomaa kaksi väitettä. He varmistavat, että testi läpäisee vain, jos kaksi riviä vastaanottavat tosi- ja vääriä vastaavista IsPhoneValid-toimintopuheluista.
Voit kysyä, mitä hyötyjä on tämän testitapauksen kirjoittamisesta? No, jos sinulla on tuhansia puhelinnumeroita vahvistettavaksi missä tahansa todellisessa tilanteessa, sinun ei tarvitse tarkistaa manuaalisesti aina, kun virheenkorjain osuu koodiin. Soita vain testikoodille tuhansia kertoja ja se kertoo, mitkä testit läpäisivät ja mitkä epäonnistuivat. Nyt sinun on tarkastettava vain epäonnistuneet.
Yksikkötestausvinkit
- Käytä aina kieltäsi tukevaa työkalua tai kehystä. Työkalujen avulla on helppo kehittää yksikkötestauksia. Saatat joutua ottamaan ylimääräisiä ponnisteluja muuten.
- Vaikka sitä suositellaan kaikkeen, joskus on kätevä ohittaa koodit, jotka ovat yksinkertaisia ja jotka eivät suoraan vaikuta järjestelmän käyttäytymiseen. Esimerkiksi getter- ja setter-koodeihin voidaan keskittyä vähemmän.
- Älä koskaan ohita koodeja, jotka vaikuttavat suoraan järjestelmään tai ovat ratkaisevan tärkeitä liiketoimintalogiikan toteutuksessa.
- Käytä testitietoja, jotka muistuttavat tuotantotietoja.
- Eristä koodi. Jos koodisi riippuu tietokannan tiedoista, älä kirjoita testitapausta soittaaksesi tietokantaan ja saadaksesi arvoja. Luo sen sijaan käyttöliittymä ja pilkata sovellusliittymää ja tietokantapuheluita.
- Ennen kuin korjaat yksikkötestauksesta johtuvan virheen, kirjoita testitapaus, joka paljastaa vian. Tähän on kolme syytä:
- Pystyt havaitsemaan korjauksestasi johtuvat regressioviat.
- Testitapauksesi on nyt kattavampi.
- Usein kehittäjä on liian laiska päivittämään testitapauksensa kirjoitettuaan.
- Liiketoiminnan logiikkaa tarkistavien testitapausten kirjoittamisen lisäksi kirjoita tapauksia, jotka testaavat myös koodisi suorituskykyä. Erityisesti silloin, kun koodeihin liittyy silmukointi, suorituskyky on eniten vaikuttanut alue.
Muistettavat asiat
- Yksikkötestitapausten tulisi olla riippumattomia
- Testattava koodi - Kaikkien koodimuutosten ei pitäisi vaatia muutosta yksikkötestauksessa, ellei itse liiketoimintalogiikka muutu. Esimerkiksi, jos logiikka vaatii nyt, että kelvollisen puhelinnumeron tulisi aina alkaa '+' -merkinnällä, yksikkötestausta on muutettava, muuten ei.
- Muu koodi - Ei pitäisi olla vuorovaikutusta tai riippuvuutta muusta koodin tai tietokannan arvosta tai sellaisesta. Yksikkö tulisi eristää testattaessa.
- Noudata testitapausten selkeitä ja johdonmukaisia nimeämiskäytäntöjä. Skenaarioiden seuraaminen on helpompaa. Voit myös käyttää versionhallintatyökaluja seurataksesi testitapauksiasi.
- Älä koskaan siirrä koodia seuraavaan vaiheeseen, ennen kuin se on tehty, virheet on korjattu ja testattu uudelleen.
- Tärkeintä on tehdä siitä tapa. Tämä on koodauskäytäntö, joka on otettava esiin. Mitä enemmän koodit ilman yksikkötestausta, sitä virheellisempi koodi on.
Ura yksikkötestauksessa
Vaikka yksikkötestaus ei ole kenttä kokonaisuutena, se on kuitenkin lisänuoli värähtelyssäsi. Se on hyvä koodauskäytäntö ja milloin hyviä koodereita ei suosita?
johtopäätös
Voidaan kiistattomasti päätellä, että yksikkötestaus voi olla toisinaan yksinkertaista ja toisinaan monimutkaista. Silloin työkalut ja kehykset tulevat pelastamaan. Edes yksikkötestauksen jälkeen koodi ei ole virhesuojattu kokonaan. Silloin seuraavan tason testausmenettelyt alkavat sisään. Kaikista näistä epävarmuustekijöistä on varmaa, että yksikkötestaus on välttämätöntä.
Suositellut artikkelit
Tämä on opas yksikkötestaukseen. Tässä keskustelimme esimerkkien kanssa yksikkötestauksen tärkeydestä, neuvoista, työkaluista, urasta ja tyyppikohdista. Voit myös käydä läpi muiden ehdotettujen artikkeleidemme saadaksesi lisätietoja -
- Haastattelukysymysten testaaminen
- Verkkotestaussovellus
- Viallinen elinkaari ohjelmistojen testauksessa
- Ura ohjelmistotestauksessa
- Luettelo Java-testauskehyksistä