http://terradunia.earth/api.php?action=feedcontributions&feedformat=atom&user=Eugenio00Y 2026-10-20T14:40:40Z Benutzerbeiträge MediaWiki 1.44.5 http://terradunia.earth/index.php?title=Co_se_stane,_kdy%C5%BE_testovac%C3%AD_pyramida_zamrzne_na_za%C4%8D%C3%A1tku_projektu&diff=164966 2026-10-11T19:48:40Z

<p>Eugenio00Y: Die Seite wurde neu angelegt: „Verzování není jen číslo v U&lt;br&gt;&lt;br&gt;Testovací pyramida není dogma. Je to nástroj, který má držet rovnováhu mezi rychlostí zpětné vazby a náklady na údržbu. Jakmile se ale požadavky začnou měnit každý sprint, klasické rozložení jednotkových, integračních a end-to-end testů přestane odpovídat realitě. Pyramidu je potřeba přizpůsobit tak, aby kopírovala místa, kde se změny skutečně dějí, ne aby zůstala hezkým obr…“</p> <hr /> <div>Verzování není jen číslo v U&lt;br&gt;&lt;br&gt;Testovací pyramida není dogma. Je to nástroj, který má držet rovnováhu mezi rychlostí zpětné vazby a náklady na údržbu. Jakmile se ale požadavky začnou měnit každý sprint, klasické rozložení jednotkových, integračních a end-to-end testů přestane odpovídat realitě. Pyramidu je potřeba přizpůsobit tak, aby kopírovala místa, kde se změny skutečně dějí, ne aby zůstala hezkým obrázkem v prezentaci.&lt;br&gt;&lt;br&gt;Vestavěné nástroje mají i limity, na které se zapomíná. Neumí spolehlivě rozpoznat dynamicky generované názvy, reflexi ani kód skládaný z řetězců. Pokud váš projekt takové konstrukce používá, automatický refaktoring je přejmenuje jen na některých místech a vznikne nekonzistence. Před hromadnou změnou si projděte, kde se symbol používá mimo staticky čitelný kód, a tato místa upravte ručně. Stejně tak dávejte pozor na veřejné rozhraní, které používají jiné projekty: přejmenování uvnitř jednoho repozitáře neznamená, že se nic nerozbije jinde.&lt;br&gt;&lt;br&gt;Co dělat, když test selže Nejužitečnější vlastností pytestu je výstup při chybě. Zatímco unittest často ukáže jen „AssertionError&quot;, pytest vypíše přesné hodnoty proměnných, které vedly k selhání. Užitečné je proto psát testy tak, aby každý ověřoval jednu konkrétní věc. Pokud test obsahuje více tvrzení za sebou a první selže, ostatní se už nespustí a přijdete o informaci, co dalšího je špatně. Tomu se dá předejít buď rozdělením do více testovacích funkcí, nebo parametrizací přes @pytest.mark.parametrize, která spustí stejný kód s různými vstupy.&lt;br&gt;&lt;br&gt;Instalace je první krok: pip install pytest. Ověřit, že vše funguje, lze příkazem pytest --version. Následně stačí vytvořit soubor s předponou test_ nebo příponou _test, například test_kalkulacka.py. Uvnitř definujete funkce, jejichž název začíná na test_. Pytest je sám najde, spustí a vyhodnotí. Žádné volání unittest.main() ani speciální runner nejsou potřeba. Spuštění celé sady je pak jen příkaz pytest v kořenovém adresáři projektu.&lt;br&gt;&lt;br&gt;Typická chyba je snaha o stoprocentní pokrytí. Pokrytí samo o sobě nic neznamená. Můžete mít devadesát procent řádků pokrytých testy, které nic neověřují, a přesto vám to nepomůže. Sledujte raději, kolik chyb unikne do produkce a jak dlouho trvá opravit rozbitou věc. Testy mají zkracovat zpětnou vazbu, ne plnit tabulku v reportu.&lt;br&gt;&lt;br&gt;Testy se do projektu nasazují v momentě, kdy začíná růst složitost a počet lidí, kteří na kódu pracují. Pokud jste jediný vývojář a píšete malý skript, který za týden smažete, nemá smysl investovat čas do testovací infrastruktury. Jakmile ale kód přežije víc než jedno vydání, začnou se v něm objevovat závislosti a přestanete si pamatovat, proč která podmínka existuje, je čas začít.&lt;br&gt;&lt;br&gt;Praktický postup je zavést kontrolu licencí do procesu sestavení. Při každém přidání nové závislosti se ověří její licence a uloží se výsledek. Před vydáním se provede souhrnná kontrola celého stromu závislostí. Pokud se objeví neslučitelná kombinace, máte tři možnosti: najít alternativní knihovnu, odstranit problematickou závislost, nebo upravit licenci projektu, pokud to je přijatelné pro všechny přispěvatele. Rozhodnutí je lepší udělat v rané fázi, kdy je změna ještě levná.&lt;br&gt;&lt;br&gt;Když začínáte s testováním v Pythonu, dříve nebo později narazíte na dvě jména: unittest a pytest. Rozdíl mezi nimi není jen v syntaxi, ale hlavně v tom, kolik práce musíte udělat, abyste vůbec mohli spustit první test. unittest je součástí standardní knihovny, pytest je potřeba doinstalovat. To je ale to nejmenší. Zásadnější je, že unittest nutí psát testy jako metody tříd dědících z TestCase, kdežto pytest pracuje s obyčejnými funkcemi a klíčovým slovem assert.&lt;br&gt;&lt;br&gt;Mezi časté chyby patří záměna příkazu assert s funkcí. V pytestu se používá prosté assert výraz, nikoli self.assertEqual. Další pastí je sdílený stav mezi testy. Pokud si testy předávají data přes globální proměnné, výsledky závisí na pořadí spuštění. Řešením jsou fixtury – funkce označené @pytest.fixture, které připraví data před každým testem znovu. Fixtura může vracet hodnotu nebo uklízet po testu pomocí yield. Díky tomu jsou testy izolované a opakovatelné.&lt;br&gt;&lt;br&gt;Pro větší projekty se vyplatí nastavit soubor pytest.ini nebo pyproject.toml, kde se dá určit, které adresáře se mají prohledávat, jak vypadá výstup nebo jaké pluginy se mají načíst. Oblíbený je například pytest-cov pro měření pokrytí kódu. Pozor ale na přehnanou snahu o stoprocentní pokrytí – testy mají odhalovat chyby, ne plnit tabulku. Začněte jednoduše, pište testy k novým funkcím a postupně přidávejte další, až když je jasné, co všechno může selhat.</div>

Eugenio00Y http://terradunia.earth/index.php?title=Benutzer:Eugenio00Y&diff=164965 2026-10-11T19:48:38Z

<p>Eugenio00Y: Die Seite wurde neu angelegt: „Někdo, kdo praktickým bydlením žije už dlouho. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.“</p> <hr /> <div>Někdo, kdo praktickým bydlením žije už dlouho. Sdílím zde, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.</div>

Eugenio00Y