Mis on ühiku testimine?

Üksuse testimine on iseenesestmõistetav sõna, kui inimene saab aru, mida üksuse all mõeldakse. Ühik on väikseim võimalik kooditükk, mida saab süsteemist loogiliselt eraldada. See tähendab, et iga kooditükki, mis võib võtta sisendeid, täita ülesannet ja genereerida väljundi ka siis, kui see on kogu süsteemist või lahendusest sõltumatu, võib nimetada ühikuks. Selle kooditüki testimist, et genereerida eeldatav väljund antud sisendikomplektil, nimetatakse ühiktestiliseks.

Ühiktestide tüübid

Arutleme mõne ühiku testimise tüübi üle.

1) Käsitsi testimine

Koodi käsitsi testimine nõuab arendajalt koodi iga rea ​​käsitsi silumist ja selle täpsuse testimist. Kui funktsionaalsus on keeruline, võib see nõuda ka samm-sammult juhiskomplekti.

2) automatiseeritud testimine

Automaatika testimisel kirjutab arendaja koodi testimiseks. Üldiselt aitab seda ühiktesti raamistike kaudu, mida tootmises ei kasutata. Muul ajal võib arendaja otsustada, et kirjutab testkoodi ilma raamistikuta ja kommenteerib selle enne juurutamist käsitsi.

Manuaalne testimine tundub enamikul juhtudel ilmselgelt aeganõudev. Kuid mõnel juhul, kui automatiseeritud testijuhtumite kirjutamine iga stsenaariumi katmiseks pole võimalik, on sageli eelistatud meetod käsitsi.

Miks on üksuse testimine oluline?

Ühiktestide olulisuse mõistmiseks peame vaatama laiemat pilti. See on osa tarkvaraarenduse elutsüklist. Vaadakem lühidalt teisi osi, et üksuse testimise rollist paremini aru saada.

Ülaltoodud pilt on lihtne näide tavalisest tarkvaraarenduse elutsüklist ja sellega seotud testimisprotsessidest. Ütlematagi selge, et sõltuvalt projekti ülesehitusest varieerub kogu protsess teatud komponentide lisamise ja eemaldamisega. Testimisprotsess hõlmab kahtlemata nelja järgmist tüüpi, nagu allpool kirjeldatud:

  • Ühiktestimine - kogu testimisprotsessi algtase. Seda teostab komponendi arendaja või mõni tema kaaslastest. Viimasel juhul nimetatakse seda tarkvaramaailmas sageli vastastikuseks testimiseks.
  • Integreerimise testimine - üksuse komponendi testimine selle lähima mooduliga. Eesmärk on kontrollida, kas seadme komponent integreerub teiste komponentidega hästi ja kas see pole mõne muu komponendi talitlushäireid põhjustanud.
  • Süsteemide testimine - kogu süsteemi testimine, kui seadme komponent on oma asendis.
  • Vastuvõtu testimine - tavaliselt teevad seda ettevõtted / kliendid, see kontrollib, kas tulemus vastab lõppkasutaja eeldatavale funktsionaalsusele.

Seega on väga hea näha, et kõik testimisprotsessid sõltuvad testimise algtasemest. Kui põhitesti ei tehta, võivad kõik muud testid olla mõttetud.

Ütleme nüüd, et teil on kood, mis koosneb kahest osast

  1. Arvutage liitintress.
  2. Lisage intress põhisummale ja arvutage tähtajaline hüvitis.

Oletame, et te ei testinud ühtegi nendest komponentidest ja asusite otse süsteemi testimisele. Süsteemi testimisel ilmneb viga, et lõppväärtus on vale. Millises koodi osas on viga?

  1. See võib olla intressi arvutamisel.
  2. See võib olla liitloogika rakendamisel.
  3. See võib olla lisaks põhisummale ka intressidele.

Vaadake, kuidas see nüüd pingutusi suurendab. Kõike seda oleks saanud vältida, kui mõlemad koodikomponendid oleksid ühiselt testitud.

Miks on üksuse testimine oluline?

  • See parandab vead alles arenguetapis. See säästab palju aega, vaeva ja kulusid. Kujutage ette, kui ühikatseid ei tehtaks, läheks kood kvaliteedi tagamise meeskonnale ja sealt edasi väga lihtsate küsimuste jaoks.
  • Head ühikatsetused täidavad ka üksikasjaliku dokumenteerimise eesmärki. Kui arendaja kirjutab ühiktestide juhtumid, kirjutab ta tahtmatult koodi eeldatava funktsionaalsuse. See on lihtsalt midagi muud, kui koodi toimimist selgitav dokumentatsioon.
  • See muudab koodi muutmise ja hooldamise lihtsaks. Kui olete koodis muudatusi teinud, viige testid uuesti läbi ja altpoolt kõik probleemid tuvastatakse probleemideta.
  • See tagab ka modulaarsuse. Ühikteste tehakse üksikute komponentidega, mis tähendab, et kood peab olema võimalikult üksikasjalik. See tagab, et kood jaotatakse asjakohaselt mooduliteks.

Mündi teine ​​külg

Sellel on ka mõned puudused. Ehkki eelised kaaluvad miinuseid, on soovitatav oma koodi alati testida, kuid samas on mõistlik teada saada sama mündi mõlemad küljed.

  • Üksikasjalik testimine, kui nii põhjalik, võib mõnikord ka kõige triviaalsemas koodis kõiki vigu tabada. Kõiki täitmisviise pole lihtsalt võimalik hinnata. Seega on ühikatsetused sageli sirgjoonelised õnnelikud ja negatiivsed stsenaariumid.
  • See nõuab arendajalt, et ta mõtleks välja ja prooviks oma koodi lahti saada. See on sageli keeruline, kuna arendaja ettekujutus kallutatakse koodi suunas.

Üksuse testimisriistad

Tööstuses on mitu tööriista, mis abistavad ühikute automaatse testimise juhtumeid. Nagu eesmärk, muudavad need arendaja jaoks ühikatestide kirjutamise ja täitmise lihtsamaks. Arendajate väljamaksete ajal on olemas üksuste testimise raamistike maailm. Allpool on loetletud mõned kõige populaarsemad ja laialdasemalt kasutatavad tööriistad.

JUnit

JUnit on Java jaoks tasuta kasutatav testimisriist. See sisaldub automaatselt paljudes JavaScripti arendamiseks mõeldud IDE-dega saadaval olevates projektimallides. JUnit teeb eriliseks see, et ta testib kõigepealt andmeid ja seejärel testib koodi pärast andmete sisestamist. See sisaldab ka väiteid katsemeetodite tuvastamiseks.

NUnit

NUnit on .Net nagu JUnit on Java. Sellel on kõik JUnit'i silmapaistvad omadused, kuid arendamiseks .Net programmeerimiskeeles. Samuti toetab see testide paralleelset läbiviimist.

PHPUnit

Sarnaselt JUnitile ja NUnitile on ka PHPUnit tööriist PHP arendajatele. See toetab ka kõiki hea testimisriista elementaarseid funktsioone.

XUnit

Teine raamistik, mis on üldisem kui tema kolleegid, on XUnit. See toetab mitut keelt, näiteks C ++, C #, ASP.Net jne. Samuti on sellel sarnased funktsioonid kui muude turul olevate tööriistade puhul.

Jtest

Parasoft Jtest on kolmanda osapoole plugin, mis koondab avatud lähtekoodiga raamistikke nagu JUnit ja lisab ühe klõpsuga lahendusi, et muuta elu lihtsamaks. Jtest abil saate genereerida oma koodi jaoks testkoodid vaid mõne klõpsuga. Neid ülesandeid automatiseerides saab arendaja töötada testjuhtumite äriloogika kallal.

QUnit

Väga populaarne JavaScripti üksuse testimise raamistik. See võib testida JavaScripti koodi nii kliendi kui ka serveri poolel.

Jasmiin

Veel üks väga laialt kasutatav JavaScripti raamistike testimisriist. Sellel on kogukonna suur toetus programmidele Angular, React jne.

JMockIt

JMockIt on avatud lähtekoodiga tööriist, mis toetab ka API-kõnede pilkamist salvestamise ja kinnitamise süntaksiga.

Üksuse katsejuhtumi näide

Mis tahes ühiktesti väga oluline nõue on testitav kood. Oletagem, et meil on funktsioon, mis kontrollib, kas telefoninumbrid on õiged (formaadi osas) või mitte. Sõltuvalt geograafilisest asukohast võib see kriteerium ka erineda. Niisiis, me ei rõhuta kriteeriume. Pigem keskendume ühiktesti juhtumile.

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. */
)
)

Nüüd peame seda kooditükki katsetama.

Saame seda käsitsi testida, sisestades mitmesuguseid väärtusi ja kontrollides väljundit. See võib esmapilgul tunduda lihtne, kuid kui koodi muudatusi tehakse, on see korduv ülesanne.

Teise võimalusena võime kirjutada ühiktesti, mis võib olla minu valideerija, kui äriloogika jääb samaks. Ühiku testjuhtum ei muutu isegi siis, kui koodi muudame. Nii, kirjutame ülaltoodud koodi jaoks ühiktesti.

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));
)

Niisiis, kuidas ülaltoodud ühiku testkood töötab? Pange tähele kahte väidet. Nad tagavad, et test läbib ainult siis, kui kaks rida saavad vastavatelt IsPhoneValid-funktsiooni kõnedelt tõese ja vale.

Te küsiksite, mis kasu on selle katsejuhtumi kirjutamisest? Noh, kui teil on tuhandetes telefoninumbrites valideerimiseks ükskõik millises reaalses stsenaariumis, ei pea te käsitsi kontrollima iga kord, kui silur koodi tabab. Helistage lihtsalt testkoodile tuhandeid kordi ja see ütleb teile, millised testid läbisid ja millised ebaõnnestusid. Nüüd peate kontrollima ainult ebaõnnestunud.

Üksuste testimise näpunäited

  1. Kasutage alati oma keelt toetavat tööriista või raamistikku. Tööriistad muudavad ühikatsete juhtumite väljatöötamise lihtsaks. Võite lõppude lõpuks lisapingutusi rakendada.
  2. Kuigi seda soovitatakse kõige jaoks, on mõnikord mugav vahele jätta koodid, mis on lihtsad ega mõjuta otseselt süsteemi käitumist. Näiteks saab getteri ja setteri koodidele vähem tähelepanu pöörata.
  3. Ärge kunagi jätke vahele koode, mis mõjutavad süsteemi otseselt või on äriloogika rakendamisel üliolulised.
  4. Kasutage katseandmeid, mis sarnanevad tootmisandmetega.
  5. Eraldage oma kood. Kui teie kood sõltub andmebaasi andmetest, ärge kirjutage andmebaasi helistamiseks ja väärtuste saamiseks proovijuhtumit. Selle asemel looge liides ja pilkake API- ja andmebaasikõnesid.
  6. Enne ühikatsetustest tuleneva vea parandamist kirjutage proov defekti paljastavast juhtumist. Sellel on kolm põhjust:
    • Teil on võimalik tuvastada teie parandusest tulenevad regressioonivead.
    • Teie testjuhtum on nüüd põhjalikum.
    • Sageli on arendaja liiga laisk, et oma katsejuhtumeid kord kirjutatud kujul värskendada.
  7. Lisaks äriloogikat kontrollivaid juhtumite kirjutamisele kirjutage lisaks ka teie koodi toimivust testivatele juhtumitele. Eriti kui koodid hõlmavad silmuseid, on jõudlus kõige enam mõjutatud ala.

Asjad, mida meeles pidada

  1. Ühiktesti juhtumid peaksid olema sõltumatud
    • Testitav kood - koodi muutmine ei tohiks nõuda ühiku testjuhtumi muutmist, välja arvatud juhul, kui äriloogika ise muutub. Näiteks kui loogika nõuab nüüd, et kehtiv telefoninumber peaks alati algama tähega „+”, siis tuleb ühiku testjuhtumit muuta, vastasel juhul mitte.
    • Teine kood - mis tahes muu koodi- või andmebaasi väärtuse või muu sellisega ei tohiks suhelda ega sõltuda. Testimisel peaks seade olema isoleeritud.
  2. Järgige oma katsejuhtumite jaoks selgeid ja järjekindlaid nimetamismeetodeid. See teeb stsenaariumide jälgimise lihtsamaks. Katsejuhtumite jälgimiseks võite kasutada ka versioonikontrolli tööriistu.
  3. Ärge kunagi edastage oma koodi järgmisse faasi, kuni see on tehtud, vead on parandatud ja uuesti testitud.
  4. Kõige tähtsam on muuta see harjumuseks. See on kodeerimise tava, mis tuleb välja õpetada. Mida rohkem te koodi ilma üksusetesteerimiseta kodeerite, seda veakam on teie kood.

Karjäär ühikatsetuses

Ehkki ühiku testimine ei ole valdkond tervikuna, on see siiski üks nool teie vutris. See on hea kodeerimise tava ja millal ei eelistata häid koodereid?

Järeldus

Võib vaieldamatult järeldada, et ühiku testimine võib mõnikord olla lihtne ja keeruline. Siis tulevad tööriistad ja raamid teie juurde. Isegi kui üksuse testimine on tehtud, pole kood täielikult tõrkekindel. Siis saab alguse järgmise taseme testimisprotseduur. Kõigist nendest ebakindlustest on kindel vaid see, et ühiku testimine on vajalik.

Soovitatavad artiklid

See on olnud üksuse testimise juhend. Siin arutasime selle näidetega üksuse testimise olulisust, näpunäiteid, tööriistu, karjääri ja tüüpe. Lisateavet leiate ka meie muudest soovitatud artiklitest -

  1. Intervjuu küsimuste testimine
  2. Veebi testimise rakendus
  3. Defektide elutsükkel tarkvara testimisel
  4. Karjäär tarkvara testimisel
  5. Java testimisraamistike loetelu

Kategooria: