Co je testování jednotek?

Testování jednotky je samo-vysvětlující slovo, pokud člověk rozumí, co se myslí jednotkou. Jednotka je nejmenší možný kód, který lze logicky izolovat od systému. To znamená, že jakýkoli kus kódu, který může přijímat vstupy, provádět úkol a generovat výstup, i když je nezávislý na celém systému nebo řešení, lze označit jako jednotku. Testování této části kódu pro generování očekávaného výstupu na dané sadě vstupů se nazývá Testování jednotky.

Druhy testování jednotek

Pojďme diskutovat o některých typech testování jednotek.

1) Ruční testování

Ruční testování kódu vyžaduje, aby vývojář ručně ladil každý řádek kódu a testoval jej na přesnost. Pokud je funkce složitá, může také vyžadovat postupné provádění instrukcí.

2) Automatické testování

Při testování automatizace vývojář zapisuje kód do testovacího kódu. Tomu obvykle napomáhají rámce Unit Test, které nejsou rozmístěny ve výrobě. Jindy se vývojář může rozhodnout napsat testovací kód bez rámce a ručně ho před implementací okomentovat.

Ruční testování se zjevně zdá být ve většině případů časově náročné. Ale v některých případech, kdy psaní automatizovaných testovacích případů pokrývá každý scénář, není možné, manuální je často preferovaná metoda.

Proč je testování jednotek důležité?

Abychom pochopili důležitost testování jednotek, musíme se podívat na širší obrázek. Je součástí životního cyklu vývoje softwaru. Podívejme se stručně na další části, abychom lépe porozuměli úloze testování jednotek.

Výše uvedený obrázek je jednoduchou ilustrací běžného životního cyklu vývoje softwaru a testovacích procesů s ním spojených. Netřeba dodávat, že v závislosti na struktuře projektu se celý proces liší s přidáváním a odebíráním určitých složek. Proces testování však s největší pravděpodobností zahrnuje čtyři typy, jak je popsáno níže:

  • Unit Testing - základní úroveň celého procesu testování. To provádí vývojář komponenty nebo kterýkoli z jeho vrstevníků. V druhém případě se ve světě softwaru často nazývá Peer Testing.
  • Testování integrace - Testování komponenty jednotky s jejím bezprostředním nadřazeným modulem. Cílem je zkontrolovat, zda se komponenta jednotky dobře integruje s ostatními komponenty a nezpůsobila selhání jiné součásti.
  • Testování systémů - Testování celého systému, když je součást jednotky umístěna na svém místě.
  • Akceptační testování - Obvykle prováděné firmou / klienty, kontroluje, zda je výsledek v souladu s funkcemi očekávanými koncovým uživatelem.

Lze tedy velmi dobře vidět, že všechny testovací procesy se spoléhají na základní úroveň testování. Pokud se základní úroveň testování neprovede, všechna ostatní testování mohou mít za následek marnost.

Řekněme, že máte kód, který má dvě části

  1. Vypočítejte úrokovou sazbu.
  2. Připojte úrok k částce jistiny a vypočítejte výhodu splatnosti.

Předpokládejme, že jste žádné z těchto komponentů netestovali a přistoupili jste přímo k testování systému. Při testování systému vzniká chyba, že hodnota splatnosti je nesprávná. Která část kódu má nyní chybu?

  1. Může to být při výpočtu zájmu.
  2. Může to být při aplikaci logiky složení.
  3. Může to být navíc k úrokům k jistině.

Podívejte se, jak to nyní zvyšuje úsilí. Tomuto všemu by se dalo zabránit, kdyby obě složky kódu byly testovány jednotkou.

Proč je testování jednotek důležité?

  • Opravuje chyby pouze ve fázi vývoje. To šetří spoustu času, úsilí a nákladů. Představte si, že by nebyly provedeny žádné jednotkové testy, kód by šel do týmu zajišťujícího kvalitu az velmi jednoduchých otázek.
  • Dobré jednotkové testy také slouží k podrobné dokumentaci. Když vývojář píše případy testů jednotek, neúmyslně zapisuje očekávanou funkčnost kódu. Jde pouze o dokumentaci, která vysvětluje fungování kódu.
  • Usnadňuje úpravu a údržbu kódu. Jakmile provedete jakékoli změny v kódu, spusťte testy znovu a viola, všechny vady jsou zachyceny bez potíží.
  • Vynucuje také modularitu. Testy jednotek jsou prováděny na jednotlivých komponentách, což znamená, že kód musí být co nejpodrobnější. Tím je zajištěno, že kód je vhodně rozdělen do modulů.

Druhá strana mince

Má také některé nevýhody. Přestože výhody převažují nad nevýhodami a vždy se doporučuje, abyste svůj kód vyzkoušeli, přesto však má smysl znát obě tváře stejné mince.

  • Testování jednotek, jak důkladné, může někdy selhat i při zachycení všech chyb v nejvýznamnějším kódu. Není jednoduše možné vyhodnotit všechny cesty provádění. Testy na jednotkách jsou tedy často přímočaré a negativní scénáře.
  • Vyžaduje, aby vývojář vymýšlel z krabice a pokusil se zlomit jeho kód. To je často obtížné, protože vnímání vývojáře je ovlivněno kódem.

Nástroje pro testování jednotek

V oboru existuje několik nástrojů, které pomáhají s automatizovanými případy testování jednotek. Díky tomu usnadňují vývojářům psaní a provádění testů jednotek. Existuje řada rámců pro testování jednotek, které jsou vypláceny vývojářům. Níže jsou uvedeny některé z nejpopulárnějších a nejpoužívanějších nástrojů.

JUnit

JUnit je bezplatný nástroj pro testování Java. Je automaticky zahrnuta do mnoha šablon projektů dostupných s různými IDE pro vývoj Java. Co dělá JUnit zvláštním je, že nejprve otestuje data a poté vloží data do kódu. Poskytuje také tvrzení k identifikaci testovacích metod.

NUnit

NUnit je .Net jako JUnit je Java. Má všechny hlavní rysy JUnit, ale pro vývoj v .Net programovacím jazyce. Podporuje také paralelní provádění testů.

PHPUnit

Podobně jako JUnit a NUnit je PHPUnit nástrojem pro vývojáře PHP. Podporuje také všechny základní vlastnosti dobrého testovacího nástroje.

XUnit

Další rámec, který je obecnější než jeho protějšky, je XUnit. Podporuje více jazyků, jako jsou C ++, C #, ASP.Net atd. Také se může pochlubit podobnými vlastnostmi jako jiné nástroje dostupné na trhu.

Jtest

Parasoft Jtest je plugin třetích stran, který využívá open source frameworků, jako je JUnit, a přidává řešení na jedno kliknutí pro usnadnění života. S Jtestem můžete automaticky generovat testovací kódy pro váš kód pouhými několika kliknutími. Automatizací těchto úkolů vývojář může pracovat na obchodní logice testovacích případů.

QUnit

Velmi populární framework pro testování jednotek JavaScriptu. Může otestovat kód JavaScript jak na straně klienta, tak na straně serveru.

Jasmín

Další velmi často používaný testovací nástroj pro rámce JavaScriptu. Má hlavní podporu komunity pro Angular, React atd.

JMockIt

JMockIt je nástroj s otevřeným zdrojovým kódem, který také podporuje zesměšňování volání API pomocí syntaxe záznamu a ověření.

Příklad případu testu jednotky

Velmi základním požadavkem každého případu testu jednotky je testovaný kód. Předpokládejme, že máme funkci, která ověřuje, zda jsou telefonní čísla správná (formátově) nebo ne. V závislosti na zeměpisné poloze se toto kritérium může lišit. Nebudeme tedy zdůrazňovat kritéria. Spíše se zaměříme na případ testu jednotky.

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

Nyní musíme otestovat tento kus kódu.

Můžeme to buď otestovat ručně vložením různých hodnot a ověření výstupu. Na první pohled se to může zdát snadné, bude to však opakovaný úkol, pokud dojde ke změně kódu.

Alternativně můžeme napsat případ testu jednotky, který může sloužit jako můj validátor, pokud obchodní logika zůstává stejná. Případ testu jednotky se nezmění, i když změníme kód. Takže pojďme napsat testovací případ jednotky pro výše uvedený kód.

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

Jak tedy výše uvedený kód testu jednotky funguje? Všimněte si dvou tvrzení Assert. Zajistí, aby test prošel pouze v případě, že tyto dva řádky obdrží pravdivé a nepravdivé z příslušných volání funkcí IsPhoneValid.

Ptáte se, jaké jsou výhody psaní tohoto testovacího případu? Pokud máte tisíce telefonních čísel k ověření v jakémkoli reálném scénáři, nemusíte ručně ověřovat pokaždé, když debugger zasáhne kód. Jednoduše zavolejte testovací kód tisíckrát a řekne vám, které testy prošly a které selhaly. Nyní stačí jen prohlédnout ty, které selhaly.

Tipy pro testování jednotek

  1. Vždy používejte nástroj nebo rámec podporující váš jazyk. Nástroje usnadňují vývoj případů testování jednotek. V opačném případě můžete vyvinout další úsilí.
  2. Přestože je doporučeno pro všechno, někdy je vhodné přeskočit kódy, které jsou jednoduché a nemají přímý dopad na chování systému. Například kódy getter a setter mohou být méně zaměřeny.
  3. Nikdy nevynechávejte kódy, které mají přímý dopad na systém nebo jsou zásadní pro implementaci obchodní logiky.
  4. Použijte testovací data, která se podobají výrobním datům.
  5. Izolujte svůj kód. Pokud váš kód závisí na datech z databáze, nepište testovací případ, kterým zavoláte databázi a získáte hodnoty. Místo toho vytvořte rozhraní a zesměšněte volání API a databáze.
  6. Před opravou chyby vzniklé při testování jednotky zapište testovací případ, který odhalí vadu. Existují tři důvody:
    • Budete schopni zachytit vady regrese, které vyplynou z vaší opravy.
    • Váš testovací případ je nyní komplexnější.
    • Vývojář je často příliš líný na to, aby aktualizoval své testovací případy, jakmile je jednou napsán.
  7. Kromě psaní testovacích případů, které ověřují obchodní logiku, také psaní případů, které testují výkon vašeho kódu. Zejména pokud kódy zahrnují opakování, je výkon nejvíce ovlivňovanou oblastí.

Co si pamatovat

  1. Jednotkové testovací případy by měly být nezávislé na
    • Testovaný kód - Jakákoli změna kódu by neměla vyžadovat změnu v případě testu jednotky, pokud se nezmění samotná obchodní logika. Například, pokud logika nyní vyžaduje, aby platné telefonní číslo mělo vždy začínat '+', pak je třeba změnit testovací případ jednotky, jinak ne.
    • Druhý kód - Neměla by existovat žádná interakce nebo závislost na jakékoli jiné hodnotě kódu nebo databáze nebo jakékoli takové věci. Jednotka by měla být při testování izolovaná.
  2. Postupujte podle jasných a konzistentních konvencí pojmenování pro své testovací případy. Usnadňuje sledování scénářů. Pomocí nástrojů pro správu verzí můžete také sledovat své testovací případy.
  3. Nikdy nepředávejte kód do další fáze, dokud není hotový, chyby jsou opraveny a znovu vyzkoušeny.
  4. A co je nejdůležitější, udělejte si ze zvyku. Toto je kódovací praxe, kterou je třeba vštípit. Čím více kódu kódujete bez testování jednotky, tím je váš kód náchylnější k chybám.

Kariéra v testování jednotek

Ačkoli testování jednotky není pole jako celek, přesto je to další šipka ve vašem touleči. Je to dobrá praxe kódování a kdy nejsou preferovány dobré kodéry?

Závěr

Lze jednoznačně dospět k závěru, že testování jednotek může být někdy jednoduché a jindy složité. To je, když nástroje a rámce přijdou k vaší záchraně. I když je testování jednotky hotové, kód není zcela odolný proti chybám. To je, když začnou postupovat testy na další úrovni. Ze všech těchto nejistot je jedinou věcí, že je nutné testování jednotek.

Doporučené články

Toto byl průvodce testováním jednotky. Zde jsme diskutovali s příklady, význam, tipy, nástroje, kariéra a typy testování jednotek. Další informace naleznete také v dalších navrhovaných článcích -

  1. Testování otázek rozhovoru
  2. Web Testing Application
  3. Životní cyklus vad při testování softwaru
  4. Kariéra v testování softwaru
  5. Seznam testovacích rámců pro Javu

Kategorie: