Edytujesz Co se stane, když testy stavíte bez pyramidy

Další častá chyba se týká parametrizace. Mnoho lidí píše pro každou kombinaci vstupů zvlášť test, což vede k obrovskému množství duplicitního kódu. Místo toho použijte @pytest.mark.parametrize. Nejenže tím zkrátíte kód, ale také zpřehledníte, které kombinace selhávají. Ale pozor – parametrizace s mnoha případy může zpomalit běh. Pokud máte desítky kombinací, zvažte, jestli některé nejsou redundantní. A vždycky si pohlídejte, aby každý parametr měl čitelné ID, jinak se v hlášeních ztratíte.<br><br>Od jednoduchého výpisu k interaktivnímu vstupu Jakmile zvládnete výpis a načtení vstupu, zkuste proměnné a základní podmínky. Například program, který se zeptá na věk a podle odpovědi vyhodnotí, zda je uživatel plnoletý. Zde narazíte na další typický problém: když uživatel zadá místo čísla text, program spadne s výjimkou. Řešením je použít int.TryParse, který vrací logickou hodnotu a vyhnete se pádu aplikace. Tím získáte kontrolu nad chybovými stavy a program bude robustnější.<br><br>Zásadní chybou začátečníků je, že do Scrumu zapojí celý tým najednou, včetně lidí, kteří s vývojem nemají nic společného. Scrum funguje jen tehdy, když je produktový owner skutečně zodpovědný za rozhodování o prioritách. Pokud tuto roli nikdo neumí plnit, Scrum se zvrhne v nekonečné diskuze. Vyberte jednoho člověka, který má právo říct „toto je důležité" a „toto počká". Bez toho bude každý sprint boj o to, čí úkol se stihne. Druhým pilířem je Scrum master, který není manažer ani sekretářka, ale facilitátor, co odstraňuje překážky.<br><br>U jednotkových testů si dejte pozor na testování implementace místo chování. Testujte, co funkce dělá, ne to, jak to dělá. Když test začnete plnit kontrolami vnitřních stavů, každá refaktorizace kódu test rozbije, i když chování zůstává stejné. U integračních testů zase hrozí, že budete testovat samotnou databázi, což je zbytečné. Zaměřte se na to, aby test prokázal, že vaše vrstvy spolu správně komunikují, ne že databáze funguje – to už ověřil její výrobce.<br><br>Dalším krokem je smyčka while, která vám umožní opakovat dotaz, dokud nezískáte platný vstup. Tím se dostanete od statického výpisu k dynamické aplikaci, která reaguje na uživatele. Nezapomeňte na proměnné typu string a int, a také na to, že porovnávání řetězců v C# je citlivé na velikost písmen – proto používejte .ToLower() nebo .ToUpper(), pokud chcete sjednotit odpovědi.<br><br>Samotné sprinty by měly být krátké, ideálně jeden až dva týdny. Delší sprinty lákají k oddalování problémů. Na začátku každého sprintu si dejte pozor na plánování, které trvá půl dne a nikam nevede. Klíčové je vybrat si jen to, co tým reálně stihne. Tip: použijte rychlost týmu (velocity) z minulých sprintů, ale neberte ji jako dogma. Pokud tým nováček, počítejte s tím, že první dva sprinty jsou o učení, ne o výkonu. Denní stand-up by měl trvat maximálně patnáct minut a měl by odpovídat jen na tři otázky: co jsem udělal, co budu dělat a co mě blokuje. Žádné dlouhé reporty, žádné řešení problémů na místě.<br><br>Častou chybou začátečníků je zapomenout na konverzi typů nebo na to, že konzolové okno se po dokončení programu okamžitě zavře. Řešení je jednoduché – na konec metody přidejte Console.ReadKey() nebo Console.ReadLine(), aby program počkal, než zmáčknete klávesu. Tento detail vám ušetří frustraci, když se vám zdá, že se aplikace spustí a hned zmizí.<br><br>Typická chyba je měřit pokrytí globálně za celý projekt. Souhrnné číslo skryje rozdíly mezi moduly — kritická platební logika může mít 30 % pokrytí, zatímco jednoduché pomocné funkce mají 95 %. Výsledný průměr pak vypadá dobře, ale riziko zůstává. Místo toho si rozdělte kód na moduly nebo vrstvy a měřte pokrytí pro každou zvlášť. Dobré pravidlo je zaměřit se na jádro systému, které se mění nejméně, a přechody mezi moduly, kde vzniká nejvíc chyb. Sledujte trend v čase, ne jen okamžitou hodnotu — pokud pokrytí klesá, je to signál, že přibývá netestovaného kódu.<br><br>Jak se vyhnout nejčastějšímu začátečnickému průšvihu Tím průšvihem je spojení větví, které se liší v mnoha souborech. Častá chyba: vy a kolega editujete stejný soubor, každý v jiné větvi. Vy uděláte commit, on také. Pak zkusíte sloučit a Git hlásí konflikt. Nejdůležitější je nezmatkovat. Otevřete soubor, najdete značky s dvojitými šipkami, přečtete obě verze a rozhodnete, co ponechat. Nikdy neprovádějte commit s konfliktem – nejprve ho vyřešte. Po úpravě nezapomeňte soubor přidat a teprve poté commitnout.<br><br>Na závěr si vyzkoušejte jednoduchý kalkulátor se sčítáním a odčítáním. To vás donutí ošetřit více vstupů a lépe pochopit logiku podmínek a převodů. Typická chyba je použití == místo = přiřazení hodnoty, nebo naopak. Také si dejte pozor na to, že Console.WriteLine může obsahovat interpolaci, ale starší syntaxe se znaménkem plus je stále funkční – vyberte si jednu a držte se jí. Po zvládnutí těchto pěti kroků budete mít solidní základ pro další práci s C# a budete umět psát jednoduché, ale funkční konzolové nástroje.