https://bigbrain.center/api.php?action=feedcontributions&feedformat=atom&user=DannSimpkinson3 2026-10-04T05:44:39Z User contributions MediaWiki 1.43.0 https://bigbrain.center/index.php?title=Kdy%C5%BE_se_testy_mno%C5%BE%C3%AD_bez_pl%C3%A1nu,_pyramidov%C3%A1_struktura_to_sprav%C3%AD&diff=93839 2026-10-02T00:20:15Z

<p>DannSimpkinson3: Created page with &quot;Druhé časté místo úniku je zpracování chyb a logování. Výjimka z databáze, která se zobrazí uživateli, prozradí strukturu dotazu, názvy sloupců i typ databáze. Útočník pak zkouší méně slepé varianty. Chybové hlášky patří do logu, ne do odpovědi prohlížeči. Stejně tak se vyhněte vracení celého dotazu v chybové zprávě, i když si myslíte, že ji vidí jen administrátor.&lt;br&gt;&lt;br&gt;Časté chyby mají společné jméno: „any&quot; a tvrz...&quot;</p> <hr /> <div>Druhé časté místo úniku je zpracování chyb a logování. Výjimka z databáze, která se zobrazí uživateli, prozradí strukturu dotazu, názvy sloupců i typ databáze. Útočník pak zkouší méně slepé varianty. Chybové hlášky patří do logu, ne do odpovědi prohlížeči. Stejně tak se vyhněte vracení celého dotazu v chybové zprávě, i když si myslíte, že ji vidí jen administrátor.&lt;br&gt;&lt;br&gt;Časté chyby mají společné jméno: „any&quot; a tvrzení typu. Když napíšete „něco as SomeType&quot;, jen tím překladateli řeknete, ať věří, že data mají tvar, který nemají. Kontrola projde a chyba se objeví až v provozu. Stejně zrádné je ignorovat návratové hodnoty funkcí, které mohou vrátit null. Řešení není složité: vždy pracujte s možností, že hodnota chybí. Pomůže volitelný řetězec „?.&quot;, výchozí hodnota přes „??&quot; a úzké typy místo širokých. Místo „string&quot; použijte konkrétní unijní typ, pokud znáte povolené hodnoty.&lt;br&gt;&lt;br&gt;U dávkového vkládání a hromadných aktualizací se často objevuje jiná chyba: aplikace spojí více hodnot do jednoho dotazu a zapomene, že počet parametrů musí odpovídat počtu zástupných symbolů. Pokud se počet neshoduje, vývojář sáhne po ručním skládání a tím vrátí injektáž zpět do hry. Bezpečnější je zpracovat dávku po menších částech nebo použít jeden připravený dotaz v cyklu, i za cenu mírně vyšší režie.&lt;br&gt;&lt;br&gt;Než uděláte první potvrzení změn, založte soubor, který vyjmenuje ignorované cesty. Bez něj se do historie dostanou tisíce souborů z knihoven a každá změna závislosti zaplaví rozdíly, ve kterých se nedá nic najít. Stejně důležité je nastavit jméno a e-mail, protože podle nich se přiřazují jednotlivé změny. Pak teprve inicializujte repozitář a přidejte první dávku souborů. Kontrolujte, co se chystá k uložení, a to ještě před samotným potvrzením.&lt;br&gt;&lt;br&gt;Druhá chyba je přílišné mockování. Když je každá závislost nahrazená atrapou, test neověří nic skutečného. Držte se pravidla: mockujte jen to, co je pomalé, nedeterministické nebo mimo vaši kontrolu. Databázi v integračních testech raději spouštějte skutečnou, klidně v kontejneru, a po každém testu ji resetujte. Testy tak zůstanou věrohodné a přitom opakovatelné.&lt;br&gt;&lt;br&gt;Testovací pyramida není dogma, ale nástroj, jak rozhodnout, kde má který test vzniknout. Vychází z jednoduché myšlenky: čím rychlejší a levnější test, tím častěji ho spouštíme. Na dně stojí jednotkové testy, uprostřed integrační a nahoře end-to-end. Pokud poměr obrátíte, sada se zpomalí, začne padat z nesouvisejících důvodů a lidé jí přestanou věřit.&lt;br&gt;&lt;br&gt;Kde pyramida v praxi selhává Nejčastější chyba je nahrazení pyramidy zmrzlinovou kornoutkem: mnoho pomalých end-to-end testů a skoro žádné jednotkové. Vzniká to tak, že se testy píší až po nasazení a přes uživatelské rozhraní. Řešení není psát víc testů, ale přesunout odpovědnost níž. Když test selže, má být jasné, která vrstva to způsobila. Pokud k opravě potřebujete spustit celou aplikaci, test je příliš vysoko.&lt;br&gt;&lt;br&gt;Začni názvy. Proměnná data, temp nebo x neříká nic. Místo d napiš datumObjednavky, místo arr klidně seznamKurzu. U funkcí používej sloveso: spocitejCenu(), nactiUzivatele(). Pokud název potřebuje komentář, je pravděpodobně špatný. Boolean pojmenuj jako tvrzení: jePrihlasen, maOpravneni, ne flag.&lt;br&gt;&lt;br&gt;Nakonec si hlídejte poměr, ale ne slepě. U malé služby může stačit pár jednotkových a jeden integrační test. U složitého systému s mnoha rozhraními bude integrační vrstva silnější. Pyramida je vodítko pro rozhodování, ne soutěž o počty. Když každý test ví, co ověřuje, a běží na správné vrstvě, sada zůstane rychlá, srozumitelná a užitečná i po letech.&lt;br&gt;&lt;br&gt;Začněte tím, že si sepíšete, co vlastně testujete. U každé části kódu si položte otázku, zda jde o čistou logiku, spolupráci komponent, nebo chování celého systému. Jednotkový test má pokrýt rozhodování, hraniční hodnoty a chybové stavy. Integrační test ověří, že spolu moduly mluví správně přes rozhraní, databázi nebo frontu. End-to-end test patří jen na kritické cesty, které musí fungovat vždy, například dokončení objednávky.&lt;br&gt;&lt;br&gt;Praktický postup je zavést pyramidu do CI postupně. Nejprve zrychlete jednotkové testy tak, aby běžely do několika sekund. Pak přidejte integrační sadu, která se spouští při každém commitu. End-to-end testy nechte na noční běh nebo před vydáním. Sledujte dobu běhu a flakiness. Každý test, který občas padá bez změny kódu, buď opravte, nebo smažte. Nespolehlivá sada je horší než žádná.</div>

DannSimpkinson3 https://bigbrain.center/index.php?title=User:DannSimpkinson3&diff=93838 2026-10-02T00:20:14Z

<p>DannSimpkinson3: Created page with &quot;Autor blogu dílnou i obývákem se zabývá denně. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.&quot;</p> <hr /> <div>Autor blogu dílnou i obývákem se zabývá denně. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.</div>

DannSimpkinson3