https://www.it-core.eu/wiki/api.php?action=feedcontributions&feedformat=atom&user=IleneKight02683 2026-09-05T01:33:19Z User contributions MediaWiki 1.44.2 https://www.it-core.eu/wiki/index.php?title=Kdy%C5%BE_testy_rostou_bez_%C5%99%C3%A1du:_Jak_stav%C4%9Bt_testovac%C3%AD_pyramidu,_kter%C3%A1_funguje&diff=199456 2026-08-29T05:00:00Z

<p>IleneKight02683: Created page with &quot;Častým nešvarem je práce na více feature větvích z jednoho lokálního klonu bez přepínání mezi nimi. Pokud máte rozjeté tři větve a v každé děláte něco jiného, snadno se stane, že začnete commitovat změny do nesprávné větve. Řešením je buď používat samostatné pracovní adresáře pro každou větev, nebo důsledně kontrolovat aktuální větev před každým commitem a pull requestem. Mnoho vývojářů si také plete stav v lokálním...&quot;</p> <hr /> <div>Častým nešvarem je práce na více feature větvích z jednoho lokálního klonu bez přepínání mezi nimi. Pokud máte rozjeté tři větve a v každé děláte něco jiného, snadno se stane, že začnete commitovat změny do nesprávné větve. Řešením je buď používat samostatné pracovní adresáře pro každou větev, nebo důsledně kontrolovat aktuální větev před každým commitem a pull requestem. Mnoho vývojářů si také plete stav v lokálním úložišti se stavem na vzdáleném serveru. Než začnete novou práci, vždy si stáhněte nejnovější změny a porovnejte, jestli vaše lokální větev odpovídá té vzdálené.&lt;br&gt;&lt;br&gt;Dalším častým problémem jsou funkce a triggery. MySQL a PostgreSQL mají odlišnou syntaxi pro uložené procedury a triggery. Většinu kódu budete muset přepsat, a to nejen kvůli syntaxi, ale i kvůli rozdílnému chování transakcí. PostgreSQL klade větší důraz na atomicitu a izolaci, což může odhalit chyby v logice, které v MySQL nebyly vidět. Otestujte všechny kritické operace, zejména ty, které zapisují více tabulek najednou.&lt;br&gt;&lt;br&gt;Při práci s databází se často zapomíná na validaci vstupů na úrovni API. Express sám o sobě žádnou validaci nenabízí, proto je vhodné použít nějakou knihovnu pro schémata. Pokud validaci podceníte, riskujete neočekávané chyby databáze, které se pak těžko debugují. Vždy si ověřte, že příchozí data odpovídají očekávanému typu a délce. A pokud narazíte na neplatný vstup, okamžitě vraťte 400 s konkrétní chybovou hláškou.&lt;br&gt;&lt;br&gt;Další pastí je slučování větví bez testování. Než začleníte feature větev do hlavní, spusťte alespoň základní sadu testů a ověřte, že se nic nerozbilo. Pokud děláte změny, které ovlivňují více částí aplikace, je vhodné provést i ruční test klíčových scénářů. Mějte na paměti, že i dokonale vyřešený merge konflikt může přinést logickou chybu, kterou testy neodhalí, pokud nejsou dostatečně pokryté. Zároveň si zvykněte po každém sloučení hlavní větve do feature větve spustit testy znovu, protože nové změny od kolegů mohly ovlivnit vaše předpoklady.&lt;br&gt;&lt;br&gt;Integrační testy: Kde se nejčastěji skrývá past Integrační testy ověřují spolupráci více komponent, obvykle s reálnou nebo téměř reálnou infrastrukturou (např. databáze, message broker). Zde je klíčové nepřehánět to s rozsahem. Místo testování celého systému se zaměřte na hranice mezi moduly, kde dochází k chybám, jako je špatná serializace, mapování nebo transakce. Pro každý takový test se snažte použít kontejnerizovanou službu, která se dá snadno spustit lokálně i v CI. Typická chyba je psát integrační testy jako plnohodnotné end-to-end scénáře — pak se stávají pomalými a duplikují práci, kterou už zvládly jednotkové testy.&lt;br&gt;&lt;br&gt;Přechod z MySQL na PostgreSQL bývá častější, než se zdá. Důvodem bývá potřeba pokročilejších datových typů, lepší podpory fulltextového vyhledávání nebo jen touha po robustnější správě souběžného přístupu. Samotná migrace ale není kopírováním souborů. Klíčové je pochopit rozdíly v chování obou systémů a připravit si data i schéma tak, aby přenos proběhl hladce.&lt;br&gt;&lt;br&gt;Při ukládání dat na zařízení zvažte, zda potřebujete Core Data, nebo postačí UserDefaults. Core Data je robustní, ale přináší složitost s migracemi a kontextem. Pro malé objemy dat, jako je nastavení, stačí UserDefaults, ale nikdy tam neukládejte velké objemy nebo citlivé informace. Pokud používáte SwiftData, pamatujte, že je to stále mladá technologie – prověřte si její chování na starších systémech. Vždy šifrujte citlivá data, ať už přes Keychain, nebo přes Security framework.&lt;br&gt;&lt;br&gt;Častým prohřeškem je tzv. obrácená pyramida, kdy je end-to-end testů více než integračních a jednotkových. To se stává, když tým nejprve psal velké scénáře a teprve později zjistil, že jsou nestabilní. Dalším problémem jsou testy, které kombinují více vrstev najednou — např. jednotkový test, který zapisuje do databáze, nebo integrační test, který ověřuje i uživatelské rozhraní. Takové testy ztrácejí svůj účel, protože při selhání nevíte, kde hledat chybu. Dobré pravidlo: jeden test by měl ověřovat jednu věc a měl by mít jasné jméno, které říká, co se děje a jaký je očekávaný výsledek.&lt;br&gt;&lt;br&gt;Základní rozhodnutí přichází hned na začátku: UIKit nebo SwiftUI? SwiftUI je deklarativní, rychlejší pro prototypy a přirozeně spolupracuje s funkcemi jako Dark Mode nebo Dynamic Type. UIKit je stabilnější a najdete pro něj více knihoven třetích stran. Pokud začínáte, vyberte si SwiftUI, ale připravte se na to, že u složitějších animací nebo custom přechodů budete muset sáhnout po UIKit reprezentacích přes UIViewRepresentable. Klíčové je nemíchat oba přístupy bez rozmyslu – držte se jedné architektury a tu konzistentně rozvíjejte.</div>

IleneKight02683 https://www.it-core.eu/wiki/index.php?title=User:IleneKight02683&diff=199454 2026-08-29T04:59:56Z

<p>IleneKight02683: Created page with &quot;Autor blogu světem interiérů sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví popisovat postupy krok za krokem.&quot;</p> <hr /> <div>Autor blogu světem interiérů sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví popisovat postupy krok za krokem.</div>

IleneKight02683