http://wiki.pannier-schulungen.de/api.php?action=feedcontributions&feedformat=atom&user=LateshaPlowman5 2026-08-22T06:27:43Z Benutzerbeiträge MediaWiki 1.28.0 http://wiki.pannier-schulungen.de/index.php?title=Kdy_m%C3%A1_smysl_zvolit_NoSQL_m%C3%ADsto_klasick%C3%A9_datab%C3%A1ze&diff=114590 2026-08-21T18:05:38Z

<p>LateshaPlowman5: Die Seite wurde neu angelegt: „Automatizované testy vám ušetří čas při opakované regresi, ale nejsou všelékem. Nejčastější chybou je testovat pouze „šťastnou cestu&quot; – ted…“</p> <hr /> <div>Automatizované testy vám ušetří čas při opakované regresi, ale nejsou všelékem. Nejčastější chybou je testovat pouze „šťastnou cestu&quot; – tedy situace, kdy vše proběhne bez chyby. Automatizaci nastavte tak, aby pokryla i chybové stavy: prázdná pole, špatný formát e-mailu, ztráta připojení k internetu, nedostatek úložiště. Pro psaní testů používejte nástroje, které umožňují běh na více zařízeních najednou, a testy rozdělte podle priority. Nízkoprioritní testy (např. vizuální kontrola) nemusí běžet při každém commitu, ale stačí je spustit před vydáním nové verze.&lt;br&gt;&lt;br&gt;Pro praktické cvičení si vytvořte jednoduchou aplikaci, která zobrazuje seznam úkolů. Použijte SwiftUI a @State pro správu dat. Přidejte možnost přidávat a mazat položky. Tím si osvojíte základní principy: vazbu dat na rozhraní, předávání dat mezi obrazovkami a práci s uživatelským vstupem. Během vývoje narazíte na to, že je nutné řešit i správu souborů nebo ukládání dat. Pro začátek stačí použít UserDefaults pro jednoduché nastavení, ale pro složitější data sáhněte po Core Data nebo SwiftData, které jsou součástí systému.&lt;br&gt;&lt;br&gt;Pro ruční testování si vytvořte kontrolní seznam, který budete procházet při každém vydání. Do seznamu zahrňte: spuštění aplikace za studena (po restartu zařízení), přepnutí do pozadí a zpět, otočení obrazovky, příchozí notifikaci, změnu jasu a hlasitosti, zapnutí a vypnutí Bluetooth a Wi-Fi. Tento seznam nemusí být dlouhý, ale musí být konzistentní – jinak na něco zapomenete. Při testování si dělejte poznámky přímo do zařízení, a to včetně času, kdy se chyba vyskytla, a kroku, který ji vyvolal. Bez těchto informací je hlášení chyby k ničemu.&lt;br&gt;&lt;br&gt;Při psaní kódu se vyhnete častému problému, pokud budete dbát na správné použití volitelných typů. Swift je striktní na nil hodnoty, a pokud se pokusíte pracovat s volitelnou proměnnou bez rozbalení, kompilátor vám to nedovolí. Mnozí začátečníci používají k vynucenému rozbalení vykřičník (!), což je riskantní. Pokud hodnota není přítomná, aplikace spadne. Místo toho používejte if let nebo guard let pro bezpečné rozbalení. Tento návyk vám ušetří hodiny ladění.&lt;br&gt;&lt;br&gt;Nakonec nezapomeňte na beta testování se skutečnými uživateli. Dejte aplikaci vybrané skupině lidí, kteří ji budou používat v běžném provozu – v metru, na horách, na pomalém připojení. Jejich zpětná vazba odhalí problémy, které vám uniknou, protože vy znáte aplikaci příliš dobře. Teprve poté, co projdete fyzickými testy, automatizací i beta verzí, můžete aplikaci vydat. Pamatujte, že testování nekončí vydáním – sledujte chybové hlášení v produkční verzi a na základě dat z reálného provozu upravte své testovací scénáře.&lt;br&gt;&lt;br&gt;Co testovat nejdřív: Priorita podle rizika Nejdůležitější je otestovat to, co může způsobit největší škodu – tedy platby, přihlašování a ochranu osobních údajů. U plateb vždy vyzkoušejte zrušení platby, opakované stisknutí tlačítka a přerušení transakce příchozím hovorem. U přihlášení ověřte, co se stane, když uživatel zadá špatné heslo pětkrát, a jak se aplikace chová po obnovení hesla. Nezapomeňte na testování s vypnutým internetem – aplikace by měla zobrazit jasnou hlášku a umožnit opakování, ne „ztichnout&quot; nebo spadnout. Typická chyba: vývojář ošetří chybu sítě, ale uživatel ji nevidí, protože aplikace zůstane na bílé obrazovce.&lt;br&gt;&lt;br&gt;Testování mobilních aplikací se od testování webových stránek liší v několika zásadních ohledech. Kromě funkčnosti musíte ověřit chování při přerušení (příchozí hovor, notifikace), různé velikosti displejů, verze operačního systému, a také spotřebu baterie či paměti. Než začnete, definujte si testovací scénáře podle reálného používání – ne podle toho, co vás napadne. Zaměřte se na hlavní uživatelské cesty, jako je registrace, přihlášení, nákup nebo synchronizace dat. U každého scénáře si zapište očekávaný výsledek, abyste ho mohli porovnat se skutečným chováním.&lt;br&gt;&lt;br&gt;Dalším častým problémem je ignorování mezer a odstupů. Návrháři používají systém mezer (často v násobcích základní jednotky, třeba 4px), aby vytvořili rytmus a oddělili logické celky. Když mezery nahradíte univerzálním paddingem nebo marginem podle toho, co zrovna vypadá dobře, rozbijete celou vizuální rovnováhu. Naučte se číst designové specifikace – v nich najdete přesné hodnoty odsazení, velikostí a barev. Pokud taková specifikace chybí, zeptejte se designéra, jaký systém používá. Je to rychlejší, než hádat a poté předělávat polovinu komponent.&lt;br&gt;&lt;br&gt;Mezi časté chyby začátečníků patří posílání obrovských pull requestů, které mění mnoho věcí najednou. Takové změny se obtížně kontrolují a často končí zamítnutím. Rozdělte práci na menší, logicky ucelené části – každý pull request by měl řešit jeden problém. Dále se vyhněte tomu, abyste se snažili vyřešit všechno najednou, nebo abyste měnili věci, které s daným problémem nesouvisí. A pozor také na to, abyste nezasahovali do cizích pull requestů bez vyzvání – počkejte, až vás maintainer požádá o spolupráci.</div>

LateshaPlowman5 http://wiki.pannier-schulungen.de/index.php?title=Benutzer:LateshaPlowman5&diff=114589 2026-08-21T18:05:37Z

<p>LateshaPlowman5: Die Seite wurde neu angelegt: „Váš průvodce dílnou i obývákem žije už dlouho. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví hledat cesty, jak si usnadnit život.“</p> <hr /> <div>Váš průvodce dílnou i obývákem žije už dlouho. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví hledat cesty, jak si usnadnit život.</div>

LateshaPlowman5