Menu

Klíč k úspěšnému testování jednotky - Jak vývojáři testují svůj vlastní kód?

key successful unit testing how developers test their own code

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Testery Black Box nestarejte se o testování jednotek. Jejich hlavním cílem je ověřit aplikaci podle požadavků, aniž bychom zašli do podrobností implementace.

Ale jako kuriozita nebo Po vybalení z krabice myšlení Přemýšleli jste někdy, jak vývojáři testují svůj kód? Jakou metodu používají k testování před vydáním kódu pro testování? Jak je testování testování důležité v agilním procesu? Odpověď na toto vše je Unit Testing. Chci vás poučit o důležitosti testování jednotek, aby vývojové a testovací týmy mohly více spolupracovat na navrhování, testování a vydávání vynikajících aplikací.

Kdo ví, že v budoucnu mohou někteří z vás dokonce přejít na testování bílé skříňky a použít tyto techniky ověřování a zlepšování kódu!

Testování jednotek

Co se naučíte:

Co je testování jednotek?

Testování jednotek není nový koncept. Je to tam od prvních dnů programování. Obvykle vývojáři a někdy Testery v bílé krabici napsat testy jednotky ke zlepšení kvality kódu ověřením každé jednotky kódu použité k implementaci funkčních požadavků (aka test řídil vývoj TDD nebo test-první vývoj).

Většina z nás možná zná klasickou definici -
'Unit Testing je metoda ověření nejmenší části testovatelného kódu proti jeho účelu.' Pokud účel nebo požadavek selhal, selhal test jednotky.

Jednoduše řečeno, to znamená - napsat část kódu (test jednotky), aby se ověřil kód (jednotka) napsaný pro implementaci požadavků.

Testování jednotek v SDLC

Testování jednotek v SDLC

V testování jednotek používají vývojáři ruční nebo automatizované testy, aby zajistili, že každá jednotka v softwaru splňuje požadavky zákazníka. Touto jednotkou může být jednotlivá funkce, objekt, metoda, postup nebo modul v testovaném softwaru.

Psaní testů jednotek k testování jednotlivých jednotek usnadňuje psaní komplexních testů, protože jsou všechny jednotky sestaveny dohromady. Během vývoje softwaru se provádí jako první úroveň testování.

Důležitost psaní testů jednotek

Testování jednotek se používá k návrhu robustních softwarových komponent, které pomáhají udržovat kód a eliminovat problémy v jednotkách kódu. Všichni víme, že je důležité najít a opravit vady v rané fázi vývojového cyklu softwaru. Toto testování slouží stejnému účelu.

Je nedílnou součástí agilního procesu vývoje softwaru. Když by měla běžet testovací sada jednotky pro noční běh sestavení a měla by být vygenerována zpráva. Pokud některý z testů jednotky selhal, neměl by tým QA přijmout toto sestavení k ověření.

Pokud to nastavíme jako standardní proces, mnoho chyb by se zachytilo v počátečním vývojovém cyklu, což by ušetřilo mnoho času na testování.

Vím, že mnoho vývojářů neradi píše testy jednotek. Ignorují nebo zapíší špatné případy testů jednotek kvůli omezenému naplánování nebo nedostatku vážnosti (ano, píší prázdné testy jednotek, takže 100% z nich úspěšně projde ;-)). Je důležité psát dobré jednotkové testy nebo je nepsat vůbec. Je ještě důležitější poskytnout Dostatek času a podpůrné prostředí pro skutečné výhody.

Metody testování jednotek

Lze jej provést dvěma způsoby:

  1. Ruční testování
  2. Automatizované testování

v Ruční testování , tester ručně provádí testovací případy bez použití jakéhokoli automatizačního nástroje. Zde se každá fáze testu provádí ručně. Ruční testování je zdlouhavé, zejména u testů, které se opakují a vyžaduje více úsilí při vytváření a provádění testovacích případů. Ruční testování nevyžaduje znalost žádného testovacího nástroje.

Je pravda, že 100% automatizace není možné, a proto bude vždy provedena určitá úroveň ručního testování.

v Automatizované testování, k automatizaci testů / testovacích případů se používají nástroje pro automatizaci testování softwaru. Automatizační nástroj může zaznamenat a uložit váš test a lze jej přehrát tolikrát, kolikrát je potřeba bez dalšího lidského zásahu.

Tyto nástroje mohou dokonce zadat testovací data do testovaného systému a také mohou porovnat očekávané výsledky se skutečnými výsledky a automaticky generovat zprávy. Počáteční náklady na nastavení nástrojů pro automatizaci testů jsou však vysoké.

Techniky v rámci testování jednotky

# 1) Bílé pole testování:

protractor end to end testing framework for angularjs apps

Při testování bílé skříňky tester zná vnitřní strukturu softwaru včetně kódu a může jej otestovat podle návrhu a požadavků. Proto je testování bílé skříňky známé také jako transparentní testování .

testování bílé skříňky

# 2) Testování černé skříňky:

Při testování černé skříňky tester nezná vnitřní struktury ani kód softwaru.

testování černé skříňky

# 3) Testování šedé skříňky:

Toto se také označuje jako poloprůhledné testování techniky což znamená, testeři jsou si vědomi jen částečně vnitřní struktury, funkcí a návrhů spolu s požadavky. Ladění se provádí skutečným vstupem z front-endu, aby se získala přesná data v back-endu. Šedá skříňka je proto považována za kombinaci testovacích technik černé skříňky a bílé skříňky.

Testování šedé skříňky

Testování v šedé krabici zahrnuje následující typy testování:

  • Maticové testování.
  • Testování vzoru.
  • Testování ortogonálních vzorů.
  • Regresní testování.

Výhody testování jednotek

  1. Proces se stává agilním: Pro přidání nových funkcí nebo funkcí do stávajícího softwaru musíme provést změny ve starém kódu. Změna věcí na již testovaný kód však může být riskantní i nákladná.
  2. Zlepšuje se kvalita kódu: Po provedení testování jednotky se kvalita kódu automaticky zlepší. Chyby identifikované během tohoto testování jsou opraveny před odesláním pro fázi testování integrace. Výsledkem je robustní design a vývoj, protože vývojáři píší testovací případy nejprve porozuměním specifikacím.
  3. Detekuje chyby dříve: Jak vývojáři spouštějí testy jednotek, detekují chyby na začátku životního cyklu vývoje softwaru a řeší je. To zahrnuje chyby nebo chybějící části ve specifikaci i chyby v implementaci programátoru.
  4. Snadnější změny a zjednodušená integrace: Testování jednotek usnadňuje vývojářům restrukturalizaci kódu, provádění změn a údržbu kódu. Také usnadňuje testování kódu po integraci. Oprava problému v Unit Testing může vyřešit mnoho dalších problémů vyskytujících se v pozdějších fázích vývoje a testování
  5. Dostupnost dokumentace: Vývojáři, kteří se této funkcionalitě budou věnovat později, se mohou obrátit na dokumentaci testování jednotek a mohou snadno najít testovací rozhraní jednotky a opravit nebo pracovat rychle a snadno.
  6. Snadný proces ladění: Pomáhá při zjednodušení procesu ladění. Pokud test v jakékoli fázi selže, je třeba ladit kód, jinak může proces pokračovat bez jakýchkoli překážek.
  7. Nižší cena: Když jsou chyby zjištěny a vyřešeny během testování jednotky, sníží se náklady a doba vývoje. Bez tohoto testování, pokud jsou stejné chyby detekovány v pozdější fázi po integraci kódu, je obtížnější dohledat a vyřešit, což je nákladnější a prodlužuje se doba vývoje.
  8. Úplnost kódu lze prokázat pomocí jednotkových testů: To je užitečnější v agilním procesu. Testeři nedostanou funkční sestavy k testování, dokud nebude dokončena integrace. Dokončení kódu nelze odůvodnit prokázáním, že jste kód napsali a zkontrolovali. Spuštění testů jednotky však může prokázat úplnost kódu.
  9. Šetří čas na vývoj: Dokončení kódu může trvat déle, ale kvůli menšímu počtu chyb v testování systému a přijetí lze ušetřit celkový čas vývoje.
  10. Pokrytí kódu lze měřit

Cyklus testování jednotky

Cyklus testování jednotky

(obraz zdroj )

Co dělá dobrý test jednotky?

Nejsem správná osoba, která by řekla, co dělá dobrý Unit Test, ale na základě mých pozorování na různých projektech můžu říct charakteristiky dobrého Unit Testu. Špatný test jednotky nepřidává projektu hodnotu. Místo toho se náklady na projekt výrazně zvyšují, psaní a správa chybných testů jednotek.

Jak psát dobré testy jednotek?

  • Test jednotky by měl být napsán k ověření jedné jednotky kódu a ne integrace.
  • Malé a izolované testy jednotky s jasným pojmenováním by velmi usnadňovaly psaní a údržbu.
  • Změna jiné části softwaru by neměla ovlivnit test jednotky, pokud jsou izolovány a zapsány pro konkrétní jednotku kódu.
  • Mělo by to běžet rychle
  • Test jednotky by měl být znovu použitelný

Jednotkové testovací rámce

Rámec testování jednotek se většinou používají k rychlému a snadnému psaní testů jednotek. Většina programovacích jazyků nepodporuje testování jednotek pomocí vestavěného kompilátoru. K tomu, aby bylo testování jednotek ještě zábavnější, lze použít open source a komerční nástroje třetích stran.

Seznam oblíbených Nástroje pro testování jednotek pro různé programovací jazyky:

  1. Rámec Java - JUnit
  2. Rámec PHP - PHPUnit
  3. C ++ rámce - UnitTest ++ a Google C ++
  4. .NET Framework - NUnit
  5. Rámec Pythonu - py.test

Mylné představy a pravdy

  • Psaní kódu pomocí testovacích případů Unit trvá déle a na to nemáme čas - ve skutečnosti by to z dlouhodobého hlediska ušetřilo váš vývojový čas.
  • Testování jednotek najde všechny chyby - nebude, protože záměrem testu jednotky není najít chyby, ale vyvinout robustní softwarové komponenty, které budou mít v pozdějších fázích SDLC méně defektů.
  • 100% pokrytí kódu znamená 100% pokrytí testu - To nezaručuje, že kód bude bezchybný.

Jak akceptovat testování jednotek?

Dobré testování jednotky lze provést ve 3 základních částech.

  1. Napište testovací kód jednotky
  2. Spusťte testovací kód jednotky a zkontrolujte, zda splňuje systémové požadavky
  3. Spusťte softwarový kód, abyste otestovali případné vady a zda kód splňuje systémové požadavky.

Po provedení výše uvedených 3 kroků, pokud se kód jeví jako správný, je test jednotky označen za úspěšný. A pokud nesplňuje systémové požadavky, test selže. V takovém případě musí vývojář znovu zkontrolovat a opravit kód.

V některých případech je nutné kód oddělit, aby bylo toto testování provedeno přesněji.

Nejlepší praxe

Chcete-li během tohoto testování vytvořit nejlepší kód, zvažte následující body:

  • Kód by měl být silný: Existují případy, kdy test selže nebo v nejhorších případech nebude vůbec spuštěn, pokud dojde k poškození kódu.
  • Pochopitelné a rozumné: Kód by měl být snadno srozumitelný. Díky tomu může vývojář snadno psát kód a dokonce i další vývojáři, kteří na kódu budou následně pracovat, budou snadno ladit.
  • Měl by to být jediný případ: Testy, které definují více případů v jednom, jsou složité pro práci. Osvědčeným postupem je tedy psaní kódu jednoho případu, díky kterému je kód snáze srozumitelný a laditelný.
  • Povolit automatizované testy: Vývojáři by se měli ujistit, že test probíhá v automatizované formě. Mělo by se jednat o nepřetržitý proces doručování nebo integrační proces.

Další body, které je třeba mít na paměti, jsou následující:

  • Místo vytváření testovacích případů pro všechny podmínky se zaměřte na test, který ovlivňuje chování systému.
  • Existuje pravděpodobnost opakování chyby kvůli mezipaměti prohlížeče.
  • Testovací případy by neměly být vzájemně závislé.
  • Věnujte také pozornost podmínkám smyčky.
  • Plánujte testovací případy častěji.

Závěr

Testování jednotky se objeví, když je nutné testovat každou funkci zvlášť. Je mnohem rozumnější detekovat a opravovat chyby během tohoto testování a šetřit čas a náklady, než hledat v pozdější fázi vývoje softwaru.

I když nabízí mnoho výhod, s jeho používáním jsou spojena i omezení. Proces vývoje softwaru vyžaduje přísnou disciplínu a důslednost překonat omezení a získat zamýšlené výhody.

Vaše komentáře jsou nejvíce vítány!
Jako tester v černé skříni, jaká jsou vaše pozorování ohledně Unit Testingu ve vašem týmu? Má někdo lepší nápad na úspěšné testování jednotek?

Doporučené čtení

^