View source for První kroky k vlastní androidí aplikaci

Při psaní testů myslete na to, že jsou to také kód. Udržujte je čisté, pojmenujte je podle toho, co ověřují, a nebojte se je refaktorovat. Dobrý test by měl být nezávislý na konkrétním pořadí spouštění, neměl by sdílet stav s jinými testy a měl by obsahovat jen jedno hlavní tvrzení. Pokud se vám daří udržet pyramidu stabilní, získáte rychlou zpětnou vazbu a bezpečí pro další změny.<br><br>Nezapomínejte ani na bezpečnost. Pokud vaše API slouží k zápisu dat, měli byste vždy ověřit, kdo požadavek posílá. Jednoduchá autentizace pomocí tokenů je minimum, které byste měli implementovat. Express vám k tomu nabízí nástroje, ale je na vás, jak je použijete. Vždy si také ošetřete velikost těla požadavku, abyste předešli zahlcení serveru. A když už píšete endpointy, které pracují s citlivými daty, nezapomeňte na šifrování přenosu pomocí HTTPS. Toto vše jsou kroky, které vaše API posunou z úrovně školního projektu na produkční kvalitu.<br><br>Testovací pyramida je jedním z nejpraktičtějších konceptů, které můžete při vývoji softwaru využít. Nejde o žádnou formalitu, ale o princip, který výrazně ovlivní stabilitu i rychlost vašeho kódu. Základní myšlenka je jednoduchá: čím nižší úroveň testu, tím rychlejší a levnější by měl být. Proto se doporučuje stavět na široké základně jednotkových testů, uprostřed mít menší vrstvu integračních testů a na vrcholu jen minimum end-to-end testů.<br><br>Když máte základní funkci, přidejte logiku pro přechod mezi obrazovkami. Bez toho se neobejde žádná praktická aplikace. Vytvořte druhou aktivitu a do té první přidejte tlačítko, které ji spustí. Nezapomeňte novou aktivitu zapsat do manifestu, jinak se při pokusu o spuštění aplikace zhroutí. Toto je jedna z nejčastějších chyb, kterou začátečníci dělají. Manifest je konfigurační soubor, kde jsou definovány všechny komponenty aplikace. Pokud tam aktivitu nezapíšete, systém ji nenajde a aplikace spadne. Proto si vždy zkontrolujte, že je manifest v pořádku, když přidáváte novou obrazovku.<br><br>Když máte API hotové, otestujte ho důkladně. Můžete použít vestavěné nástroje v prohlížeči nebo si napsat jednoduchý skript, který projde všechny endpointy. Důležité je ověřit nejen happy path, ale i chybové stavy – co se stane, když pošlete neplatné ID, prázdné tělo nebo špatnou metodu. Testy vám dají jistotu, že se vaše API chová konzistentně a že po nasazení do produkce nebudete muset hasit zbytečné požáry. Tímto způsobem se vyhnete většině problémů, na které začátečníci u Expressu narazí, a vaše REST API bude stabilní a použitelné pro reálné aplikace.<br><br>Až budete mít aplikaci funkční, zaměřte se na testování. Nezůstávejte jen u toho, že aplikace funguje na vašem telefonu. Vyzkoušejte ji na emulátoru s jinou verzí systému a případně na dalším zařízení, pokud ho máte k dispozici. Sledujte, jak se chová při rychlém přepínání obrazovek, při otáčení displeje nebo při nedostatku paměti. Všechny tyto situace mohou odhalit skryté chyby. Jakmile máte pocit, že je aplikace stabilní, můžete přemýšlet o jejím zveřejnění. Ale to už je téma na další článek – nejdřív si užijte pocit, že jste vytvořili něco, co opravdu funguje.<br><br>Při návrhu REST API v Node.js se Express stal de facto standardem. Než začnete psát první endpoint, mějte jasno v tom, co vaše API skutečně potřebuje. Základní kostra je jednoduchá – stačí vytvořit instanci aplikace, nadefinovat port a spustit posluchač. Ale pozor, samotné spuštění serveru nestačí. Důležité je hned na začátku nastavit správné middleware, jako je parsování JSON těla a logování požadavků. Bez nich narazíte na problémy, když začnete testovat reálné požadavky z prohlížeče nebo z externího klienta.<br><br>Typickou chybou bývá snaha nahradit jednotkové testy end-to-end testy, protože se zdají být „realističtější". Výsledkem je sada testů, které běží desítky minut a jsou extrémně křehké. I malá změna v uživatelském rozhraní pak způsobí selhání celého scénáře, i když je logika v pořádku. Místo toho se vždy snažte většinu chování ověřit na nižších úrovních a end-to-end testy používejte pouze jako pojistku pro hlavní tok.<br><br>Třetí úskalí spočívá v tom, že lidé často spouští kontejnery interaktivně bez náležitého přepínače. Pokud potřebujete vejít do běžícího kontejneru a prozkoumat ho, použijte docker exec -it název_kontajneru sh. Bez -it se nedostanete do interaktivního shellu a budete jen bezradně koukat na výstup. Také si zvykněte na pravidelný úklid: příkaz docker system prune smaže nepoužívané obrazy, kontejnery a sítě, čímž uvolní místo na disku. Naopak se vyvarujte mazání kontejnerů, které právě běží – vždy je nejprve zastavte příkazem docker stop.