Što je testiranje jedinice?
Jedinstveno testiranje je riječ koja nije razumljiva ako razumijemo što se podrazumijeva pod Jedinica. Jedinica je najmanji mogući komad koda koji se može logički izolirati iz sustava. To znači da bilo koji komad koda koji može uzimati unose, obavljati zadatak i generirati izlaz čak i ako je neovisan od cijelog sustava ili rješenja, može se nazvati Jedinicom. Testiranje ovog dijela koda radi generiranja očekivanog izlaza na određenom skupu ulaza naziva se testiranje jedinice.
Vrste ispitivanja jedinica
Razgovarajmo o nekim vrstama jedinica testiranja.
1) Ručno testiranje
Ručno testiranje koda zahtijeva od razvojnog programera da ručno ukloni pogrešku u svakom retku koda i testira ga na točnost. Možda će biti potrebna i korak po korak set uputa ako je funkcionalnost složena.
2) Automatizirano testiranje
U testiranju za automatizaciju, programer piše kod kako bi testirao kod. To se uglavnom pomaže kroz okvire jedinice ispitivanja koji nisu raspoređeni u proizvodnji. Inače, programer može odabrati pisanje testnog koda bez okvira i ručno komentirati prije uvođenja.
Ručno testiranje očito izgleda dugotrajno u većini slučajeva. No, u nekim slučajevima kada pisanje automatiziranih testnih slučajeva za svaki scenarij nije moguće, priručnik je često poželjna metoda.
Zašto je ispitivanje jedinice važno?
Da bismo shvatili važnost testiranja jedinice, moramo pogledati širu sliku. To je dio životnog ciklusa razvoja softvera. Ukratko razmotrimo ostale dijelove da bismo bolje razumjeli ulogu Jedinstvenog testiranja.
Gornja slika je jednostavan prikaz normalnog životnog ciklusa razvoja softvera i procesa ispitivanja koji su s njim povezani. Nepotrebno je reći da ovisno o strukturi projekta, cijeli postupak varira s dodatkom i uklanjanjem određenih komponenti. Proces testiranja, međutim, zasigurno uključuje četiri vrste kako su dolje opisane:
- Ispitivanje jedinice - osnovna razina čitavog procesa ispitivanja. To izvodi programer komponente ili bilo koji od njegovih kolega. U potonjem se slučaju često naziva i Peer Testing u programskom svijetu.
- Integration Testing - Ispitivanje jedinice sa svojim neposrednim roditeljskim modulom. Cilj je provjeriti je li komponenta jedinice dobro integrirana s ostalim komponentama i nije li prouzročila neispravnost bilo koje druge komponente.
- Ispitivanje sustava - Ispitivanje cijelog sustava kad se jedinica jedinice postavi na svoje mjesto.
- Ispitivanje prihvaćanja - obično se obavlja od strane poduzeća / klijenata, provjerava usklađuje li ishod s funkcionalnošću koju očekuje krajnji korisnik.
Stoga se vrlo dobro vidi da se svi postupci testiranja oslanjaju na elementarnu razinu ispitivanja. Ako osnovna razina ispitivanja nije izvršena, sva ostala ispitivanja mogu rezultirati uzaludnim.
Recimo sada da imate kôd koji ima dva dijela
- Izračunajte složene kamate.
- Dodajte kamate glavnici i izračunajte dospijeće.
Pretpostavimo da niste testirali jedinice niti jednu od ovih komponenti i nastavili izravno s testiranjem sustava. Prilikom ispitivanja sustava pojavljuje se pogreška što vrijednost zrelosti nije ispravna. Koji dio koda ima pogrešku?
- Može biti u obračunu kamata.
- To može biti u primjeni složene logike.
- Mogu biti i kamate glavnice.
Pogledajte, kako se to sada povećava. Sve to bi se moglo izbjeći da su obje komponente koda testirane.
Zašto je ispitivanje jedinice važno?
- Popravlja bugove samo u fazi razvoja. To štedi puno vremena, truda i troškova. Zamislite da nije bilo jedinice provedene jedinice, kôd bi išao od tima za osiguranje kvalitete za vrlo jednostavne probleme.
- Dobri testovi jedinice također služe svrhu detaljne dokumentacije. Kada programer piše testne slučajeve jedinice, nehotice piše očekivanu funkcionalnost koda. To jednostavno nije samo dokumentacija koja objašnjava rad koda.
- Omogućuje jednostavno mijenjanje i održavanje koda. Nakon što unesete bilo kakve promjene u kôd, pokrenite testove ponovo i viole, svi nedostaci uhvatit će se bez problema.
- Također provodi modularnost. Jedinstveni testovi izvode se na pojedinim komponentama, što znači da kôd treba biti što precizniji. To osigurava da se kôd prikladno podijeli na module.
Druga strana novčića
Ima i nekih nedostataka. Iako prednosti imaju prednost nad nedostacima i preporučuje se testiranje koda, ipak ima smisla znati oba lica iste kovanice.
- Ispitivanje jedinice, kako dosad temeljito, ponekad može uspjeti uhvatiti sve pogreške i u najtrivijalnijem kôdu. Jednostavno nije moguće procijeniti sve puteve izvršenja. Stoga su jedinični testovi jednostavni scenariji sretnog puta i negativni.
- Zahtijeva programer da razmišlja izvan okvira i pokušava razbiti svoj kod. To je često teško jer percepcija programera postaje pristrana prema kodu.
Alat za ispitivanje jedinice
U industriji postoji nekoliko alata koji pomažu u automatiziranim testnim slučajevima. Kao svrha, programeru olakšavaju pisanje i izvršavanje testnih slučajeva jedinica. Postoji svijet okvira okvira za testiranje jedinica na raspravi programera. U nastavku su navedeni neki od najpopularnijih alata koji se najčešće koriste.
JUnit
JUnit je besplatni alat za testiranje Java. Automatski se uključuje u mnoge predloške projekata dostupne s različitim IDE-ima za razvoj Java. Ono što JUnit čini posebnim jest to što prvo testira podatke, a zatim testira kod nakon umetanja podataka u njih. Također pruža tvrdnje za identifikaciju metoda ispitivanja.
NUnit
NUnit je na .Net kao JUnit na Javu. Ima sve istaknute značajke JUnit-a, ali za razvoj u .Net programskom jeziku. Također podržava paralelno pokretanje testova.
PHPUnit
Slično kao JUnit i NUnit, PHPUnit je alat za PHP programere. Također podržava sve elementarne značajke dobrog alata za testiranje.
XUnit
Drugi okvir koji je generičkiji od svojih kolega je XUnit. Podržava više jezika poput C ++, C #, ASP.Net itd. Također se može pohvaliti sličnim značajkama kao i ostali alati dostupni na tržištu.
Jtest
Parasoft Jtest je dodatak treće strane koji koristi okvire otvorenog koda poput JUnit i dodaje rješenja jednim klikom kako bi olakšao život. Pomoću Jtest-a možete automatski generirati testne kodove za svoj kôd sa samo nekoliko klikova. Automatizirajući ove zadatke, programer je slobodan raditi na poslovnoj logici testnih slučajeva.
QUnit
Vrlo popularan okvir za testiranje JavaScript jedinice. Može testirati JavaScript kôd i na strani klijenta i na strani poslužitelja.
Jasmin
Još jedan vrlo često korišteni alat za testiranje okvira okvira JavaScript. Ima veliku podršku u zajednici za Angular, React, itd.
JMockIt
JMockIt je alat otvorenog koda koji također podržava ismijavanje API poziva s sintaksom snimanja i provjere.
Primjer test jedinice
Vrlo osnovni zahtjev svakog testnog slučaja jedinice je kôd koji se testira. Pretpostavimo da imamo funkciju koja potvrđuje jesu li telefonski brojevi točni (u obliku formata) ili ne. Ovisno o zemljopisnom položaju, ovaj kriterij također može varirati. Dakle, nećemo naglasiti kriterije. Radije ćemo se usredotočiti na testni slučaj jedinice.
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. */
)
)
Sada moramo testirati ovaj dio koda.
Možemo ga i ručno testirati umetanjem različitih vrijednosti i provjerom izlaza. Na prvi pogled ovo može izgledati jednostavno, ali biti će ponovljen zadatak ako se u kôdu promijeni bilo kakva promjena.
Alternativno, možemo napisati testni slučaj koji može poslužiti kao moj validator sve dok poslovna logika ostane ista. Jedinica za testiranje jedinice neće se promijeniti čak i ako promijenimo kod. Dakle, napišimo jedinicu test slučaja za gornji kod.
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));
)
Pa kako funkcionira gornji testni kod jedinice? Zapazite dva izvještaja o stanju. Osiguravaju da test prolazi samo ako dvije linije primaju istinito i lažno od odgovarajućih poziva IsPhoneValid.
Pitali biste koje su prednosti pisanja ovog testnog slučaja? Pa, ako imate tisuće telefonskih brojeva za potvrdu u bilo kojem stvarnom scenariju, ne morate ručno provjeravati svaki put kada program za uklanjanje pogrešaka udari u kod. Jednostavno nazovite testni kod tisućama puta i on će vam reći koji su testovi prošli, a koji nisu. Sada trebate samo pregledati one koji nisu uspjeli.
Savjeti za ispitivanje jedinice
- Uvijek koristite alat ili okvir koji podržava vaš jezik. Alati olakšavaju izradu testnih slučajeva jedinica. U suprotnom možete uložiti dodatne napore.
- Iako se preporučuje za sve, ponekad je prikladno preskočiti jednostavne kodove koji ne utječu izravno na ponašanje sustava. Na primjer, kodova za postavljanje i postavljanje mogu se manje fokusirati.
- Nikada ne preskačite kodove koji izravno utječu na sustav ili su ključni za implementaciju poslovne logike.
- Koristite testne podatke koji nalikuju podacima proizvodnje.
- Izolirajte svoj kod. Ako vaš kôd ovisi o podacima iz baze, nemojte pisati testni slučaj da biste nazvali bazu podataka i dobili vrijednosti. Umjesto toga, stvorite sučelje i ismijavajte API i pozive iz baze podataka.
- Prije nego što popravite pogrešku koja je nastala testiranjem jedinice, napišite test slučaj koji otkriva kvar. Tri su razloga za to:
- Moći ćete uhvatiti regresijske nedostatke koji proizlaze iz vašeg popravljanja.
- Vaš je testni slučaj sada sveobuhvatniji.
- Razvojni programer je često lijen da jednom ažurira svoje testne slučajeve.
- Uz pisanje testnih slučajeva koji potvrđuju poslovnu logiku, pišite i slučajeve koji testiraju performanse koda. Učinkovitost kada kodovi uključuju petlje, izvedba je područje koje je najviše pod utjecajem.
Stvari koje treba zapamtiti
- Slučajevi jedinice moraju biti neovisni o
- Kôd koji se testira - Svaka promjena koda ne bi trebala zahtijevati promjenu u slučaju jedinice jedinice, osim ako se sama poslovna logika ne promijeni. Na primjer, ako logika sada zahtijeva da valjani telefonski broj uvijek započne s '+', tada treba promijeniti telefonski test jedinice, u suprotnom ne.
- Drugi kôd - Ne bi trebalo postojati nikakva interakcija ili ovisnost s bilo kojim drugim dijelom koda ili baze podataka ili bilo kakvim takvim. Jedinica treba biti izolirana tijekom ispitivanja.
- Slijedite jasne i dosljedne konvencije o imenovanju za testne slučajeve. To olakšava praćenje scenarija. Možete koristiti i alate za kontrolu verzija za praćenje svojih testnih slučajeva.
- Nikada ne prenesite svoj kôd na sljedeću fazu dok to nije učinjeno, greške su ispravljene i ponovno testirane.
- Najvažnije je da to postane navika. Ovo je praksa kodiranja koju treba uključiti. Što više šifrirate bez testiranja jedinice, vaš je kod skloniji pogreškama.
Karijera u ispitivanju jedinica
Iako testiranje uređaja nije polje u cjelini, ipak je to dodatna strelica u vašem drvoredu. To je dobra praksa kodiranja i kada se dobri koderi ne preferiraju?
Zaključak
Može se nesporno zaključiti da je testiranje jedinice ponekad jednostavno i složeno. Tada vam pomažu alati i okviri. Čak i uz obavljeno testiranje jedinice, kod nije u potpunosti dokaz pogreške. Tada je započeo postupak testiranja na sljedećoj razini. Između svih ovih nesigurnosti, jedino je sigurno da je nužno testiranje jedinica.
Preporučeni članci
Ovo je vodič za ispitivanje jedinica. Ovdje smo razgovarali o važnosti, savjetima, alatima, karijeri i vrstama ispitivanja jedinica s njegovim primjerima. Možete i proći naše druge predložene članke da biste saznali više -
- Ispitivanje pitanja o intervjuima
- Prijava za web testiranje
- Neispravan životni ciklus u testiranju softvera
- Karijere u testiranju softvera
- Popis okvira za testiranje za Javu