Mis on ühikutestimine?

Mis on ühikutestimine?

Ühiktestimine on tarkvara testimise meetod, kus koodi üksused või komponendid— näiteks funktsioonid, meetodid või klassid — testitakse eraldi, et kontrollida nende korrektset toimimist. Eesmärk on valideerida, et rakenduse väikseimadki osad käituvad ootuspäraselt ilma sõltuvusteta välistest süsteemidest.

A üksus võib olla nii väike kui üks funktsioon või nii suur kui väike moodul, olenevalt sellest, kuidas tarkvara on loodud. Põhiprintsiip on isolatsioonVäliseid ressursse, nagu andmebaasid, API-d või failisüsteemid, tuleks imiteerida või tükeldada, et test keskenduks ainult üksuse loogikale.

Näiteks Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

See lihtne test kontrollib, kas add funktsioon tagastab õige tulemuse. Kuigi see on triviaalne, demonstreerib see ideed: enne ülejäänud süsteemiga integreerimist tuleb loogikat kontrollida iseseisvalt.

Ühiktestimise harjutamise abil loovad arendajad turvavõrk mis tuvastab kiiresti regressioonid, toetab refaktoreerimist ja parandab tarkvara hooldatavust.

Üksuse testimise video selgitus

Miks teha ühikutesti?

Üksuse testimine on oluline, sest tarkvaraarendajad püüavad mõnikord aega kokku hoida minimaalse ühiktestimisega ja see on müüt, kuna sobimatu ühiktestimine toob kaasa defektide parandamise kõrged kulud. Süsteemi testimine, Integratsioonitestimine, ja isegi beetatestimist pärast rakenduse valmimist. Kui varajases arendusjärgus tehakse korralik ühiktestimine, säästab see lõpuks aega ja raha.

Siin on peamised põhjused, miks tarkvaratehnikas ühiktestimist teha:

• Varajane vigade avastamine – Probleemid kerkivad pinnale nende tekkimise lähedal, mistõttu on lahendused kiiremad ja odavamad.
• Parandatud koodi kvaliteet – Puhas ja testitav kood viib sageli parema arhitektuuri ja vähemate varjatud sõltuvusteni.
• Regressioonikaitse – Ühiktestid toimivad refaktoreerimise ajal turvavõrguna, tagades vanade funktsioonide töö jätkumise.
• Kiiremad arendustsüklid – Automatiseeritud testid lühendavad kvaliteedikontrolli tagasisidetsükleid ja vähendavad käsitsi testimise üldkulusid.
• Suurem meeskonna enesekindlus – Tänu ulatuslikule ühiktestimisele saavad arendajad värskendusi juurutada teadmisega, et need ei riku olemasolevaid funktsioone.

Lühidalt: Ühiktestimine säästab aega, vähendab riske ja parandab töökindlustSee muudab testimise valusast järelmõttest ennetavaks inseneripraktikaks.

Kuidas ühiktestimist läbi viia?

Usaldusväärne ühiktestimise voog on etteaimatav, kiire ja automatiseeritud. Kasutage seda kuueastmelist tsüklit, et hoida kvaliteet kõrge ja tagasiside kiire.

1. samm) Analüüsige üksust ja määratlege juhtumid

Tuvastage väikseim testitav käitumine. Loetlege õnnelikud teed, äärejuhtumidja veatingimusedSelgitage sisendeid/väljundeid ning eel- ja järeltingimusi.

2. samm) Testikeskkonna seadistamine

Valige raamistik, laadige minimaalselt kinnitusvahendeid ja isoleerida sõltuvused (viibimised/tõlgid/võltsingud). Hoidke seadistus kerge, et vältida aeglaseid ja hapraid teste.

3. samm) Kirjutage test (AAA muster)

Korraldama sisendid ja kontekst → tegu helistades seadmesse → Väide oodatav tulemus. Eelista käitumuslikke väiteid sisemiste rakendusdetailide asemel.

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

4. samm) Käivita lokaalselt ja CI-s

Käivita esmalt oma masinal testid; seejärel käivita puhta keskkonna kontrollimiseks CI-s. Kiire ebaõnnestumine; hoia logid kokkuvõtlikud ja praktilised.

5. samm) Vigade diagnoosimine, parandamine ja ümbertegemine

Kui test ebaõnnestub, paranda kood või test, mitte mõlemat korraga. Pärast rohelist refaktoreeri enesekindlalt – testib valvuri käitumist.

6. samm) Käivita uuesti Revvaata ja säilita

Käivita kogu komplekt uuesti. Eemalda ebaühtlased testid, dedubleeritud kinnitusdetailid ja jõusta katvuskünnised ilma neid manipuleerimata. Märgistage aeglased testid, et neid harvemini käivitada.

Pro nõuanded:

• Jätka teste kiire (<200 ms igaüks) ja sõltumatud.
• Nimeta testid käitumine (nt test_total_includes_tax).
• Käsitle ebastabiilsust veana; pane karantiini, kõrvalda algpõhjus ja seejärel luba uuesti.

Millised on erinevad ühiktestimise tehnikad?

Ühiktestid on kõige tõhusamad, kui neid kombineerida nutikad testimisdisaini tehnikad koos mõistlikud katvuseesmärgidPüüdke laiuse poole seal, kus see on oluline, sügavuse poole seal, kus risk on suurim, ja vältige „100% või languse“ lõksu.

. Üksuse testimise tehnikad jagunevad peamiselt kolmeks osaks:

1. Musta kasti testimine mis hõlmab kasutajaliidese testimist koos sisendi ja väljundiga
2. Valge kasti testimine hõlmab tarkvararakenduse funktsionaalse käitumise testimist
3. Halli kasti testimine kasutatakse testikomplektide, testimismeetodite ja testijuhtumite käivitamiseks ning riskianalüüsi tegemiseks

Katvus on a juhtiv indikaator, mitte finišijoon. Kasuta seda selleks, et leida pimealasid, mitte numbriga mängimiseks. Ühiktestimisel kasutatavad koodi katmise tehnikad on loetletud allpool:

• Väljavõtte katvus
• Otsuste katvus
• Filiaalide katvus
• Seisundi katvus
• Piiratud olekuga masina katvus

Lisateavet koodi katvuse kohta leiate aadressilt https://www.guru99.com/code-coverage.html

Milline on pilkamise ja tsenseerimise roll ühiktestimisel?

Ühiktestid peaksid keskenduma ainult testitavale koodile — mitte selle sõltuvused. Sinna pilkab ja kännu tule sisse. Need „testi duublid” asendavad reaalseid objekte, et saaksite isoleerida käitumist, kontrollida sisendeid ja vältida aeglaseid või ebaühtlaseid teste.

Miks kasutada testi Doubles?

• Isolatsioon – Testi ainult seadet, mitte andmebaasi, võrku ega failisüsteemi.
• Determinism – Kontrolli väljundeid ja kõrvalmõjusid, et tulemused oleksid järjepidevad.
• Kiirus – Testid töötavad millisekundites, kui need ei puutu kokku väliste süsteemidega.
• Äärmusjuhtumi simulatsioon – Jäljenda hõlpsalt vigu (nt API ajalõpp) ilma neid päriselus ootamata.

Tüved

A stub on lihtsustatud asendus, mis tagastab fikseeritud vastuse. See ei salvesta interaktsioone — see lihtsalt annab konserveeritud andmeid.

Näide (Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

Pilkamised

A mõnitama on võimsam: see suudab kontrollida interaktsioone (nt „kas seda meetodit kutsuti välja X-iga?”).

Näide (JavaSkript koos Jestiga):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

Siin, mõnitama kontrollib, kas e-posti teenust kutsuti õigesti – midagi, mida tüvi ei saa teha.

Tavalised lõksud

• Liigne pilkamine – Kui iga kaastöötajat pilgatakse, muutuvad testid hapraks ja seotuks rakenduse üksikasjadega.
• Nägemuste testimine käitumise asemel – Keskendu võimaluse korral tulemustele (oleku/tagastusväärtused) interaktsioonide asemel.
• Lekkiv seadistuskood – Hoidke näidised/tõlgid kerged; loetavuse tagamiseks kasutage abilisi või kinnitusvahendeid.

Rusikareeglid

• Tükelda, kui sul on lihtsalt andmeid vaja.
• Mock, kui teil on vaja interaktsioone kinnitada.
• Eelista võltsinguid tugevatele moedele kui võimalik (nt mälusisene andmebaas iga päringu pilkamise asemel).

Alumine rida: Pilkamine ja kägistamine on kõrvalosatäitjad, mitte tähti. Kasuta neid oma üksuse isoleerimiseks, aga ära lase neil testimiskomplekti kaaperdada.

Millised on levinumad ühiktestimise tööriistad?

Saadaval on mitu automatiseeritud seadmetesti tarkvara, mis aitavad tarkvara testimisel üksuse testimist. Toome allpool mõned näited:

1. JUnitJunit on tasuta kasutatav testimistööriist, mida kasutatakse Java programmeerimiskeel. See pakub väiteid testimismeetodi tuvastamiseks. See tööriist testib esmalt andmeid ja seejärel lisab need koodijuppi.
2. NUnitNUnit on laialdaselt kasutatav ühiktestimise raamistik kõigile .NET-keeltele. See on avatud lähtekoodiga tööriist, mis võimaldab skripte käsitsi kirjutada. See toetab andmepõhiseid teste, mis saavad paralleelselt töötada.
3. PHPUnitPHPUnit on PHP programmeerijatele mõeldud ühiktestimise tööriist. See võtab väikeseid koodiosasid, mida nimetatakse ühikuteks, ja testib igaüht neist eraldi. Tööriist võimaldab arendajatel kasutada ka eelnevalt määratletud kinnitusmeetodeid, et kinnitada süsteemi käitumist teatud viisil.

Need on vaid mõned saadaolevatest üksuste testimise tööriistadest. Neid on palju rohkem, eriti C keeled ja Java, aga kindlasti leiate oma programmeerimisvajadustele sobiva ühiktestimise tööriista, olenemata kasutatavast keelest.

Testipõhine arendus (TDD) ja üksuse testimine

Ühiktestimine TDD-s hõlmab testimisraamistike ulatuslikku kasutamist. Ühiktestimise raamistikku kasutatakse automatiseeritud ühiktestide loomiseks. Ühiktestimise raamistikud pole TDD-le ainuomased, kuid on selle jaoks olulised. Allpool vaatleme, mida TDD ühiktestimise maailma pakub:

• Testid kirjutatakse enne koodi
• Toetuge suuresti testimisraamistikele
• Kõiki rakendustes olevaid klasse testitakse
• Võimalik on kiire ja lihtne integreerimine

Siin on mõned TDD eelised:

• Soodustab väikeseid, testitavaid üksusi ja lihtsaid kujundusi.
• Väldib üleprojekteerimist; ehitad ainult seda, mida test nõuab.
• Pakub refaktoritele elavat turvavõrku.

EkspertnõuandedVali TDD, kui soovid range disaini tagasiside koodi tasandil ja kiire, järkjärguline edasiminek ühikute osas.

Miks integreerida ühiktestid CI/CD-sse?

Ühiktestid pakuvad kõige rohkem väärtust siis, kui need on otse süsteemi sisse lülitatud. pideva integratsiooni ja pideva edastamise (CI/CD) torujuheSelle asemel, et olla järelmõte, saavad neist kvaliteetne värav mis valideerib automaatselt iga muudatuse enne selle saatmist.

Siin on põhjused, miks integreerida ühiktestid CI/CD torujuhtmetesse:

• Kohene tagasiside – Arendajad saavad minutite jooksul teada, kas nende muudatus midagi katki tegi.
• Shift-vasakpoolne kvaliteet – Vigu püütakse leida muudatuste tegemise ajal, mitte pärast avaldamist.
• Usaldus juurutuste vastu – Automatiseeritud kontrollid tagavad, et „rohelisi ehitisi” on ohutu edasi viia.
• Skaleeritav koostöö – Igas suuruses meeskonnad saavad koodi ühendada üksteisele peale astumata.

Ühiku testimise müüt

Siin on mõned levinud müüdid ühiktestimise kohta:

„See võtab aega ja mul on alati ülekoormatud aega. Minu kood on kivikõva! Ma ei vaja ühikteste.“

Müüdid on oma olemuselt valed oletused. Need eeldused viivad nõiaringini järgmiselt:

Tõde on see, et ühiktestimine kiirendab arendust.

Programmeerijad arvavad, et integratsioonitestimine püüab kinni kõik vead ja ei käivita ühiktesti. Kui ühikud on integreeritud, võtab väga lihtsate vigade, mida oleks ühiktestimise käigus lihtne leida ja parandada, leidmine ja parandamine väga kaua aega.

Üksuse testimise eelis

• Arendajad, kes soovivad teada saada, milliseid funktsioone üksus pakub ja kuidas seda kasutada, saavad vaadata üksuse teste, et saada üksuse API-st põhiteadmised.
• Ühiktestimine võimaldab programmeerijal koodi hiljem ümber faktoriseerida ja veenduda, et moodul töötab endiselt korrektselt (nt Regressioonitestimine). Protseduur on kõigi funktsioonide ja meetodite testjuhtumite kirjutamine, nii et kui muudatus põhjustab tõrke, saab selle kiiresti tuvastada ja parandada.
• Seadmetestimise modulaarse olemuse tõttu saame testida projekti osi, ootamata teiste valmimist.

Üksuse testimise puudused

• Ühiktestimiselt ei saa eeldada, et see suudab leida kõik programmi vead. Isegi kõige triviaalsemates programmides pole võimalik hinnata kõiki täitmisteid.
• Ühiktestimine keskendub oma olemuselt koodiühikule. Seega ei suuda see tuvastada integratsioonivigu ega laiaulatuslikke süsteemitaseme vigu.

Ühiktestimist on soovitatav kasutada koos teiste testimistegevustega.

Üksuse testimise parimad tavad

• Ühiktestide juhtumid peaksid olema sõltumatud. Nõuete täiustused või muudatused ei tohiks ühikteste mõjutada.
• Testige korraga ainult ühte koodi.
• Järgige oma ühikutestide puhul selgeid ja järjepidevaid nimetamistavasid
• Koodimuutuste korral mis tahes moodulis veenduge, et oleks olemas vastav üksus Testjuhtum mooduli jaoks ja moodul läbib testid enne juurutuse muutmist
• Seadme testimise käigus tuvastatud vead tuleb enne SDLC järgmisse faasi minekut parandada
• Kasutage lähenemist "testi oma koodina". Mida rohkem koodi ilma testimiseta kirjutate, seda rohkem teid peate vigade kontrollimiseks.

KKK

kokkuvõte