https://bigbrain.center/api.php?action=feedcontributions&feedformat=atom&user=DanniePuckett81 2026-10-04T11:44:45Z User contributions MediaWiki 1.43.0 https://bigbrain.center/index.php?title=4_n%C3%A1vyky,_kter%C3%A9_rozhoduj%C3%AD_o_kvalit%C4%9B_test%C5%AF_v_NUnit&diff=93551 2026-10-01T23:19:25Z

<p>DanniePuckett81: Created page with &quot;Se složkami a kopiemi pracuj vědomě. Operátor = u objektů a polí nekopíruje, jen vytvoří další odkaz. Když potřebuješ skutečnou kopii, použij spread ...obj nebo [ ...arr ]. Pozor ale na mělkou kopii: vnořené objekty zůstávají sdílené. U funkcí používej const jako výchozí volbu, let jen tam, kde se hodnota skutečně mění, a var nech stranou. Stejně tak sáhni po map, filter a reduce místo ručních cyklů s for a pomocnými poli, pokud jd...&quot;</p> <hr /> <div>Se složkami a kopiemi pracuj vědomě. Operátor = u objektů a polí nekopíruje, jen vytvoří další odkaz. Když potřebuješ skutečnou kopii, použij spread ...obj nebo [ ...arr ]. Pozor ale na mělkou kopii: vnořené objekty zůstávají sdílené. U funkcí používej const jako výchozí volbu, let jen tam, kde se hodnota skutečně mění, a var nech stranou. Stejně tak sáhni po map, filter a reduce místo ručních cyklů s for a pomocnými poli, pokud jde o transformaci dat.&lt;br&gt;&lt;br&gt;Na vrcholu stojí end-to-end testy. Ověřují scénář z pohledu uživatele, ale jsou nejdražší na údržbu. Nemá smysl jimi pokrývat každou kombinaci vstupů. Vyberte kritické cesty: přihlášení, platba, uložení objednávky. Pokud e2e test padá kvůli změně textu v tlačítku, je příliš křehký a patří do nižší vrstvy. Stabilita je důležitější než pokrytí.&lt;br&gt;&lt;br&gt;Začněte tím, že si tým rozdělí práci na malé celky. Pokud větev žije déle než dva dny, rozpadá se na konflikty a ztracený kontext. Praktické pravidlo: jedna větev = jedna logická změna, kterou lze popsat jednou větou. Když popis potřebuje „a zároveň&quot;, rozdělte ji. Větve pojmenovávejte krátce a konkrétně, například oprava-prihlaseni nebo platebni-formular. Vyhněte se jménům jako vetev1, test nebo nova-verze.&lt;br&gt;&lt;br&gt;Jazyk je další rozhodnutí. Pro Android dnes dává smysl učit se Kotlin, protože je oficiálně podporovaný a nové projekty se v něm zakládají. Java funguje taky, ale narazíš na starší návody, které tě mohou mást. Vyber si jeden a drž se ho. Střídání mezi oběma na začátku jen zpomalí učení. Stejně tak je zbytečné učit se dva přístupy k rozvržení najednou. Začni s tím, který je v aktuálních ukázkách.&lt;br&gt;&lt;br&gt;Praktický postup: nejdřív napište jednotkový test pro novou logiku, pak integrační pro hranici systému a e2e jen pro scénář, který by jinak nikdo neověřil. Sledujte dobu běhu. Pokud sada jednotkových testů trvá déle než několik sekund, něco děláte špatně. Pokud integrační testy vyžadují ruční spuštění databáze, ztratí se v CI a přestanou se spouštět.&lt;br&gt;&lt;br&gt;Největší chybou je poměr obrátit: mnoho e2e testů a málo jednotkových. Další je sdílený stav mezi testy. Test, který projde sám, ale selže v sadě, obvykle závisí na datech z předchozího běhu. Řešením je izolace a deterministická data. Pyramidu nevnímejte jako početní poměr, ale jako rozhodnutí, kde zaplatíte za rychlost a kde za věrnost.&lt;br&gt;&lt;br&gt;První aplikace nemusí být originální. Udělej jednoduchý seznam úkolů nebo převodník jednotek. Cílem je projít celým cyklem: návrh, kód, test, oprava. Až bude fungovat, zkus přidat jednu vlastnost navíc. Tím se učíš nejrychleji. Mobilní vývoj není o tom naučit se všechno předem, ale o tom vydržet u jednoho malého projektu dost dlouho na to, aby fungoval.&lt;br&gt;&lt;br&gt;Čtvrtý návyk je práce s výjimkami a parametrizací. Pro očekávané výjimky používejte Assert.Throws nebo Assert.That s Throws.TypeOf, nikdy ne obalení do try-catch s prázdným blokem. Parametrizované testy s [TestCase] nebo [TestCaseSource] ušetří desítky metod a zpřehlední hraniční hodnoty. Pozor ale na přílišnou abstrakci: pokud parametr mění i logiku testu, ne jen vstup, patří zvlášť. Nakonec testy pravidelně spouštějte lokálně i v rámci sestavení, jinak ztratí smysl. Test, který se nespouští, je jen komentář s horší syntaxí.&lt;br&gt;&lt;br&gt;Když se větev rozroste, merge bolí Nejčastější chyba je dlouhé odkládání merge. Čím déle větev stojí, tím víc se hlavní linie vzdaluje a tím víc ručního slévání vás čeká. Řešení je rebase proti mainu dělat průběžně, ne až na konci. Rebase přepíše historii větve, takže ji nikdy nedělejte na větvi, kterou už někdo jiný stáhl k sobě. Pokud na větvi pracuje víc lidí, použijte merge z mainu do větve místo rebase. Tím zachováte společnou historii a vyhnete se zmatkům.&lt;br&gt;&lt;br&gt;Když narazíš na chybu, nekopíruj slepě řešení z diskuzí. Přečti si, co přesně hlásí konzole. Většina problémů má jednoznačnou příčinu a zpráva ji často přímo pojmenuje. Nauč se používat ladicí nástroje a sledovat logy. To zkrátí hledání z hodin na minuty. Také si zvykni ukládat projekt průběžně do nějakého systému pro verzování. Jedna nechtěná změna může jinak smazat hodiny práce.&lt;br&gt;&lt;br&gt;Většina týmů se zasekne na tom, jestli pracovat s dlouho žijícími větvemi, nebo commitovat rovnou do hlavní linie. Rozdíl není v nástroji, ale v tom, jak rychle dokážete dostat změnu k ostatním a jak drahé je vrátit ji zpět. Trunk-based vývoj znamená, že každý den mergujete do main; feature branch znamená, že změna žije odděleně, dokud není hotová. Ani jedno není univerzálně správné.&lt;br&gt;&lt;br&gt;Testovací pyramida není dogma, ale nástroj na řízení rizika. Většina týmů skončí u opačného extrému: stovky jednotkových testů, které procházejí, a přesto se aplikace rozbije při prvním kliknutí. Problém nebývá v počtu testů, ale v tom, co který test skutečně ověřuje. Pyramidu je proto lepší brát jako poměr mezi rychlostí zpětné vazby a věrností produkčnímu prostředí.</div>

DanniePuckett81 https://bigbrain.center/index.php?title=User:DanniePuckett81&diff=93549 2026-10-01T23:19:24Z

<p>DanniePuckett81: Created page with &quot;Váš průvodce dílnou i obývákem žije už dlouho. Sdílím zde, jak zvládnout domácnost bez stresu. Nejraději popisovat postupy krok za krokem.&quot;</p> <hr /> <div>Váš průvodce dílnou i obývákem žije už dlouho. Sdílím zde, jak zvládnout domácnost bez stresu. Nejraději popisovat postupy krok za krokem.</div>

DanniePuckett81