Častou chybou je spoléhat na escapování znaků ručně. Funkce pro úpravu řetězců se liší podle databáze i podle kódování a snadno se na některý znak zapomene. Escapování může být nouzové řešení ve starším kódu, ale nikdy by nemělo být hlavní strategií. Stejně tak nestačí kontrolovat jen délku nebo typ vstupu. Útočník může poslat platné číslo, které však v kontextu dotazu způsobí nečekaný výsledek.

Než nainstaluješ cokoli dalšího, rozhodni se, na čem budeš pracovat. Pro Android je oficiální cestou Android Studio, které obsahuje potřebné nástroje pro kompilaci, ladění i testování. Stačí jej stáhnout, nainstalovat a nechat doběhnout prvotní konfiguraci. Během ní si nainstaluj SDK pro alespoň jednu starší a jednu novější verzi systému. Emulátor si nastav tak, aby odpovídal zařízení, na kterém chceš aplikaci reálně testovat – ideálně telefon s běžným rozlišením a rozumnou pamětí.

Integrační vrstva odhalí to, co unit testy nikdy nemohou Integrační testy ověřují spolupráci mezi komponentami – například že se data správně uloží do databáze, že API vrací správný formát nebo že se zpráva odešle do fronty. Na rozdíl od unit testů mohou používat reálné závislosti, ale v izolovaném prostředí (testovací databáze, kontejnery). Běžně jich stačí 15–20 %. Pozor na dvě věci: první je sdílený stav mezi testy. Pokud testy běží paralelně a sahají na stejná data, budou jeden druhému přepisovat výsledky. Druhá je přílišná složitost – integrační test nemá simulovat celý svět, ale jednu konkrétní hranici.

Typická chyba je tichý posun. Když zjistíte, že to nestíháte, čekáte, jestli to doženete, a zákazníkovi to řeknete, až když je pozdě. To je horší než původně špatný odhad. Informaci o posunu dodejte ve chvíli, kdy ji máte, spolu s novým odhadem a důvodem. Zákazník nesnáší překvapení víc než zpoždění. Pokud mu dáte čas zareagovat, často si sám upraví priority nebo ubere rozsah.

Jakmile první aplikace běží, nespěchejte s jejím zveřejněním. Nechte ji týden používat někým jiným a sledujte, kde se zasekne. Verzujte kód od prvního dne, i když pracujete sami. Zvykněte si psát krátké popisy změn, které za půl roku pochopíte. Až budete mít hotové dvě až tři malé aplikace, teprve pak má smysl řešit publikaci, propagaci a další růst. Do té doby je každá hodina strávená u kódu investicí, která se vrátí v podobě klidnějšího vývoje.

Neignorujte chybová hlášení. Podrobná chybová zpráva z databáze prozradí názvy tabulek, sloupců i typy dat a útočníkovi výrazně usnadní další postup. V produkčním prostředí proto zapněte obecné chybové stránky a podrobnosti logujte pouze na server. Totéž platí pro ladící nástroje, které nesmí být veřejně dostupné.

Největší past je snaha mít 100% pokrytí. Pokrytí je vedlejší ukazatel, ne cíl. Mnohem důležitější je, zda testy odhalí regresi v kritických částech systému. Začněte tam, kde chyby bolí nejvíce – platby, přihlášení, zpracování dat. Až poté řešte zbytek. Pokud tým nemá čas psát testy, není to problém testů, ale priorit. Struktura testů musí odpovídat riziku, ne ideologii.

Ladění berte jako běžnou součást práce, ne jako trest. Nastavte si logování s jasnými značkami a čtěte výpisy chyb odshora dolů, protože příčina bývá v prvních řádcích, ne v posledním. Při každé chybě si napište do poznámek, co ji způsobilo. Po měsíci budete mít vlastní seznam, který je cennější než jakýkoli kurz. Nebojte se používat simulátor pro rychlé kontroly a skutečný telefon pro chování na dotyk, baterii a pomalé síti.

Kde začátečníci nejčastěji ztrácejí čas Největší pastí je snaha napsat všechno ručně. Layout skládejte z hotových prvků a vlastní kreslení si nechte na okamžik, kdy opravdu narazíte na limit. Druhou pastí je ukládání dat přímo v obrazovce. Jakmile aplikaci zavřete a otevřete, přijdete o stav a začnete psát záplaty. Naučte se proto oddělit zobrazení od logiky hned na prvním projektu, i když to znamená více souborů. Třetí pastí je testování pouze na jednom zařízení. Rozdíly ve velikosti displeje, verzi systému a výkonu odhalí problémy, které emulátor na notebooku nikdy neukáže.

End-to-end testy mají nejmenší zastoupení, obvykle 5–10 %. Ověřují kritické scénáře z pohledu uživatele: přihlášení, dokončení objednávky, odeslání formuláře. Jsou pomalé a křehké, protože závisí na prohlížeči, síti i datech. Typická chyba je psát end-to-end testy pro každou novou funkci. Mnohem lepší je pokrýt jimi jen to, co nelze spolehlivě ověřit níže. Každý takový test by měl mít jasný důvod existence a měl by být součástí CI, ale ne na úkor rychlosti zpětné vazby.