Když testy rostou bez řádu: Jak je zkrotit pyramidou
Nakonec si osvojte zvyk odhadovat v hodinách, ne ve dnech. Den je příliš hrubá jednotka a snadno v ní skryté činnosti zaniknou. Pokud ale pracujete v kratších úsecích, lépe si uvědomíte, kolik času skutečně věnujete jednotlivým činnostem. Po zkušenosti s deseti úkoly zjistíte, že vaše odhady se stávají přesnějšími a vy se můžete soustředit na to, co je opravdu důležité – na dodání funkčního řešení v dohodnutém termínu.<br>
<br>
<br>
<br>
Pro práci s webem a stahováním dat si osvojte knihovnu requests. Umožňuje posílat HTTP požadavky a zpracovávat odpovědi. Když stahujete stránky, vždy nastavte uživatelský agent, jinak vás servery mohou blokovat. Také respektujte pravidla serveru, neposílejte příliš mnoho požadavků za sekundu. Pro zpracování HTML odpovědí se hodí knihovna BeautifulSoup, která umožňuje najít potřebné elementy podle CSS selektorů. Pozor na to, že webové stránky se často mění, takže skripty na scrapování vyžadují údržbu. Než napíšete složitý scraper, zkuste zjistit, jestli stránka nenabízí API, které je stabilnější.<br>
<br>
<br>
<br>
Kde nejčastěji pyramida padá a jak to napravit Nejčastější chybou je obrácená pyramida – když máte stovky end-to-end testů a jen pár jednotkových. Tým pak tráví více času opravováním testů než vývojem funkcí. Příčinou bývá snaha testovat všechno přes uživatelské rozhraní, protože „to je nejvěrnější obraz toho, co uživatel vidí". Jenže takový přístup ignoruje, že každý end-to-end test je pomalý a náchylný k selhání kvůli načasování, animacím nebo změnám v rozvržení. Řešení není testy mazat, ale přesunout většinu scénářů na nižší úrovně. Logiku, která se skrývá za formulářem, otestujte na úrovni jednotek nebo integrace. End-to-end testy si nechte jen na kritické cesty – přihlášení, platbu nebo registraci.<br>
<br>
<br>
<br>
Při práci s Reduxem v Reactu narazíte na jeden zásadní problém: jakmile začnete ukládat do store vše, co vás napadne, aplikace se začne zpomalovat. Redux totiž není databáze ani univerzální úložiště pro všechny komponenty. Jeho smysl je centralizovat stav, který je skutečně globální – přihlášení uživatele, nastavení motivu, košík. Lokální stav jako text v inputu, otevřený dropdown nebo dočasná hodnota formuláře by měl zůstat v useState nebo useReducer. Jinak každý úhoz do klávesnice spustí update celého stromu komponent, které jsou na store navázané, a to je cesta k trhání.<br>
<br>
<br>
<br>
Testovací pyramida není jen hezký obrázek z přednášek o kvalitě kódu. Je to praktický nástroj, který vám pomůže udržet testovací sadu rychlou, stabilní a hlavně užitečnou. Pokud ji ignorujete, dříve nebo později narazíte na situaci, kdy spuštění všech testů trvá hodiny, každá změna v kódu rozbije desítky testů a nikdo už neví, co vlastně testy ověřují. Tento článek se zaměřuje na to, jak pyramidu skutečně použít, na co si dát pozor a jakým chybám se vyhnout.<br>
<br>
<br>
<br>
Nakonec si uvědomte, že žádné IDE není univerzální. To, co vyhovuje kolegovi, nemusí vyhovovat vám. Vyzkoušejte si alespoň dva kandidáty na reálném projektu – ne na ukázkovém příkladu. Všímejte si, jak rychle se vám píše kód, jak snadno se pohybujete mezi soubory a jak vám prostředí pomáhá při hledání chyb. Teprve pak se rozhodněte, s kterým budete pracovat dlouhodobě.<br>
<br>
<br>
<br>
Nejlepší způsob, jak pokrytí měřit, je kombinovat více pohledů. Řádkové pokrytí je nejjednodušší, ale snadno vás uvede v omyl — kód může být „pokrytý", ale testy neobsahují žádná relevantní tvrzení. Pokrytí větví ukazuje, zda se procházejí všechny rozhodovací cesty, což je užitečnější, ale stále neříká nic o datech, která testy používají. Praktický postup: pro důležité části kódu sledujte pokrytí větví, pro kritické moduly pak pokrytí podmínek nebo mutační testování, které cíleně mění kód a ověřuje, zda testy takovou změnu odhalí. Jen tak zjistíte, jestli testy skutečně něco hlídají.<br>
<br>
<br>
<br>
Jak se vyhnout nejčastějším chybám při psaní skriptů Když píšete skript pro automatizaci, vždy předpokládejte, že se něco pokazí. Soubor může chybět, připojení může selhat nebo data nemusejí mít očekávaný formát. Proto používejte výjimky (try a except) a logování. Další častou chybou je neuvážené mazání souborů. Místo os.remove radši soubor nejdřív přesuňte do dočasné složky a po kontrole teprva smažte. Nikdy nepoužívejte funkce, které mažou rekurzivně, bez předchozího ověření, že pracujete ve správné složce. Tím se vyhnete katastrofě, kdy skript smaže polovinu disku.<br>
<br>
<br>
<br>
Nakonec si hlídejte výkonnost celé aplikace. Redux je skvělý nástroj, ale pokud ho používáte na každou drobnost, stává se přítěží. Použijte React.memo nebo useMemo na komponenty, které odebírají data ze store, a zvažte, zda některé části stavu nemají zůstat lokální. Pokud aplikace začne být pomalá, zkontrolujte, kolik komponent se re-renderuje při jedné akci – to je ukazatel, že máte příliš mnoho závislostí. Dobrým testem je přidat do komponenty console.log s názvem komponenty a sledovat, kdy se loguje. Často zjistíte, že se vykreslují i ty, které se změny netýkají.