Než napíšeš první test, pochop tyto tři věci

Klíčová je automatizace. Nástroje pro automatické testy vám ušetří hodiny práce, ale mají háček: automatizovat byste měli jen stabilní funkce, které se často opakují. Typická chyba začátečníků je snaha automatizovat úplně všechno, včetně vizuálních změn, které se každý sprint mění. Výsledkem je pak neudržovatelný testovací kód, který se musí přepisovat častěji než samotná aplikace.

Než začnete s verzováním, zkuste si nejprve nacvičit na malém projektu. Vytvořte si testovací repozitář, kde budete experimentovat s větvemi, slučováním a vracením změn. Tím získáte jistotu bez rizika, že rozbijete produkční kód. Dále si zvykněte na pravidelný commit – ideálně každou hodinu, když je práce smysluplná. Vyhnete se tak ztrátě dat a budete mít jemnou historii změn. Mějte na paměti, že verzování není jen o ukládání kopií, ale o vytváření přehledného příběhu vašeho projektu.

Začněte tím, že si ujasníte rozdíl mezi testováním na emulátoru a na reálném zařízení. Emulátor je rychlý a levný, ale neodhalí problémy s výkonem, s GPS, s fotoaparátem nebo s citlivostí dotykové obrazovky. Pro prvotní ověření logiky aplikace ho používejte, ale před vydáním vždy testujte na minimálně pěti reálných zařízeních s různými verzemi operačního systému a různým rozlišením.

Redux není nástroj, který by se hodil do každé aplikace. Pokud teprve začínáte, často narazíte na doporučení sáhnout po něm hned na začátku. To je ale cesta k tomu, že strávíte hodiny psaním boilerplate kódu a akcí, které ve skutečnosti žádný problém neřeší. Než Redux vůbec do projektu přidáte, položte si otázku, zda vaše aplikace skutečně sdílí stav mezi mnoha komponentami, nebo zda se data pohybují jen lokálně.

Dalším praktickým tipem je rozdělit práci na etapy a komunikovat průběžně. Pokud zákazník ví, že první část bude hotová za dva dny, druhá za týden, má lepší přehled a necítí potřebu neustále kontrolovat. Tím snižujete tlak na sebe i na něj. Důležité je také nikdy neslibovat víc, než můžete splnit. Pokud si nejste jistí, raději řekněte delší termín a pak ho zkraťte – to vždy potěší. Naopak zkrácení termínu, na který jste přistoupili jen kvůli tlaku, vede téměř jistě ke zklamání.

Na závěr si dejte pozor na přehnané množství pluginů. Instalace desítek rozšíření může zpomalit prostředí a způsobit konflikty. Vybírejte jen to, co skutečně využijete, a pravidelně kontrolujte, která rozšíření jsou aktivní. Pokud si osvojíte práci s klávesovými zkratkami a využijete vestavěné funkce, zjistíte, že většinu úkolů zvládnete bez zbytečných přídavků. Rozhodnutí o IDE by nemělo být jednorázové – po půl roce práce se vyplatí znovu vyhodnotit, jestli vám nástroj stále vyhovuje, a případně přejít na efektivnější řešení.

Při prvních krocích se vyvarujte časté chyby: commitujte až příliš velké změny naráz. Místo toho rozdělte práci do logických celků. Každý commit by měl obsahovat jednu konkrétní změnu, třeba opravu chyby nebo přidání nové funkce. K tomu vždy napište výstižnou zprávu, která popisuje, co a proč jste změnili. Nikdy necommitujte tajně soubory, které obsahují hesla, API klíče nebo jiné citlivé údaje. Pro tyto případy existují soubory typu .gitignore, které určují, které soubory se nemají sledovat.

Důvěra se buduje dlouhodobě. Pokud jednou dodáte pozdě, ale s vysvětlením a náhradním řešením, zákazník to pochopí. Pokud se to opakuje, přestane vašim odhadům věřit úplně. Proto si před každým slibem položte otázku: „Co všechno se může pokazit a jak to ovlivní termín?" Nechte si rezervu na technické problémy, nemoc, čekání na podklady. A když práci dokončíte dříve, než jste slíbili, je to vždy příjemné překvapení, které posiluje vaši důvěryhodnost.

Dalším praktickým krokem je rozdělení kódu na moduly, které se starají o jednu doménu. Jeden modul by měl obsahovat akce, reducer i selektory pro konkrétní část stavu. Vyhnete se tak obrovským souborům, kde se po pěti minutách ztratíte. Místo abyste psali nové akce pro každou drobnost, používejte factory funkce, které vám vrátí akci s typem a payloadem. To zpřehlední kód a zároveň usnadní testování, protože každou funkci můžete volat izolovaně.

Testování mobilních aplikací se často podceňuje. Tým spěchá na termín, ruční testy proběhnou narychlo a první ostré nasazení odhalí, že aplikace padá na starších telefonech nebo že se uživatelé nedostanou k platbě. Přitom stačí dodržet několik základních pravidel a většině problémů se vyhnete.

Pozor si dejte na testování sítě. Mobilní aplikace se používají na špatném signálu, s přepínáním mezi Wi-Fi a mobilními daty nebo úplně offline. Simulujte tyto situace nástroji, které omezí rychlost připojení nebo ho úplně vypnou. Typický problém, který takto odhalíte, je aplikace, která po obnovení připojení zobrazí nesprávná data nebo se zacyklí.