První unit test: kde začít a na co si dát pozor

From Rikkiepedia
Jump to navigation Jump to search

Typická chyba začátečníků je testovat příliš mnoho v jednom testu. Jeden test by měl ověřovat jedno chování. Pokud testujete formátování data, neověřujte zároveň práci s časovými pásmy. Pokud test selže, mělo by být okamžitě jasné, která část kódu je rozbitá. Další častý problém je spoléhat se na konkrétní implementaci – test pak musíte měnit pokaždé, když upravíte vnitřek metody. Testujte rozhraní, ne to, jak metoda funguje uvnitř.

Při testování si všímejte nejen funkčnosti, ale i použitelnosti (UX). Zapisujte každý nedostatek srozumitelně a reprodukovatelně: postup, očekávaný výsledek, skutečný výsledek. To je přesně to, co dělá profesionální tester. Výstup poté zpracujte do formátu, který vypadá jako z reálné firmy – s čísly verzí, prostředím a datem. Takový „portfolio projekt" ukáže na pohovoru víc než teoretická znalost.

Jak převést návrh do funkčního kódu bez zbytečných chyb Při implementaci designu se nejčastěji chybuje v detailech, které na první pohled nevypadají důležité. Například ignorování stavů prvků: hover, focus, active, disabled. Uživatelé s klávesnicí nebo čtečkou obrazovky potřebují viditelný focus. Proto vždy nastavte viditelný outline pro klávesové ovládání, a to nejen v CSS, ale i v JavaScriptu – pokud nějaký prvek dynamicky přidáváte, nezapomeňte mu nastavit příslušné ARIA atributy. Dále si hlídejte velikost cílových oblastí – tlačítka by měla mít minimálně 44×44 pixelů, aby se na ně dobře trefilo prstem na dotykovém zařízení. Kontrolujte také kontrast textu vůči pozadí; WCAG doporučuje poměr alespoň 4,5:1 pro běžný text.

První kroky: vytvořte si vlastní testovací projekt Nejefektivnější způsob, jak nahradit chybějící praxi, je simulovat reálné testování. Stáhněte si volně dostupnou webovou aplikaci nebo mobilní hru (nemusíte ji kupovat) a začněte ji systematicky procházet. Vytvořte si tabulku, do které zapíšete testovací scénáře: co očekáváte, co se stalo, a jaký je stupeň závažnosti případné chyby. Zaměřte se na hraniční hodnoty, prázdná pole, neplatné vstupy nebo chování při pomalém připojení.

Časté chyby, které kazí čistotu Mezi typické chyby patří používání magických čísel – hodnot bez vysvětlení, například if (status === 3). Místo toho definujte konstantu STATUS_APPROVED = 3 a používejte ji. Podobně se vyvarujte dlouhým řetězením podmínek if…else; pokud jich je víc než dvě, zvažte použití objektu nebo mapy pro mapování stavů. Také se vyhněte mutování vstupních parametrů – místo toho vracejte nové hodnoty, což usnadňuje ladění.

Typickou chybou je spoléhat se na defaultní chování prohlížeče. Například odesílání formuláře stisknutím Enteru je sice výchozí, ale pokud máte vlastní validaci, musíte zajistit, aby proběhla i při tomto způsobu odeslání. Nebo když vytváříte vlastní dropdown, musíte ošetřit klávesové zkratky (šipky, Escape, Tab) a správně nastavit aria-expanded. Vždy testujte, co se stane, když uživatel zaklikne pole, ale nevyplní ho – jaká chybová hláška se objeví a jak je srozumitelná. Chybová hláška by měla být konkrétní: „Zadejte platný e-mail" místo „Chyba ve formuláři".

První kroky: obrázky a komprese Začněte s obrázky – tvoří obvykle největší část přenesených dat. Místo uložení fotky o šířce 2000 pixelů a jejím zmenšení pomocí HTML použijte optimalizovaný soubor o skutečné velikosti zobrazení. Formát WebP nebo AVIF nabízí výrazně menší velikost při zachované kvalitě. Pokud musíte použít klasický JPG, zkuste nástroj pro kompresi bez ztráty kvality. Pozor na další častý problém: několik velkých fontů. Omezte jejich počet a použijte systémové písmo, kdykoli je to možné.

Nakonec si zvykněte testy spouštět automaticky, ideálně při každém uložení nebo před odesláním změn do sdíleného repozitáře. Pokud testy běží až večer, je snadné je ignorovat. Rychlá zpětná vazba je klíčová. Nebojte se, že první testy budou pomalé nebo že jich bude málo. Každý test, který projde, vám dává jistotu. Až narazíte na chybu, kterou test odhalí, pochopíte, proč se vyplatí je psát.

Začít kariéru v testování softwaru bez praxe je reálné, ale vyžaduje to cílenou přípravu. Firmy často hledají juniory, kteří znají základy testovacího procesu a mají analytické myšlení. Místo snění o první nabídce se zaměřte na to, co můžete udělat ještě dnes: naučte se, jak se píše testovací případ, a osvojte si nástroje pro hlášení chyb.

Během přípravy si vytvořte strukturovaný životopis, kde místo pracovní historie uvedete „Vlastní testovací projekty" a konkrétní ukázky: kolik chyb jste nalezli, jaké typy testů jste provedli, jaké nástroje jste používali. U pohovoru se nevyhýbejte otázce, proč nemáte praxi – vysvětlete, co jste se naučili, a ukažte svůj portfolio. Důležité je, abyste mluvili o tom, co jste dělali, ne o tom, co neumíte.