Když chcete psát testy v Pythonu, vyzkoušejte pytest a vyhněte se chybám

2026-08-29T03:26:50Z

NathanielMcReyno: Created page with "Až budete mít hotové rozvržení, otestujte ho na skutečných zařízeních. Jenom změna šířky okna v prohlížeči nestačí. Mobilní prohlížeče mají jiné chování při posouvání a klávesnice může změnit rozměry. Zkuste si stránku otevřít na mobilu s vypnutým připojením – uvidíte, jak se chovají obrázky a text. Správně nastavený Grid a Flexbox by měly držet obsah čitelný i bez načtených fontů. Pokud se rozvržení rozpadne, je..."

Až budete mít hotové rozvržení, otestujte ho na skutečných zařízeních. Jenom změna šířky okna v prohlížeči nestačí. Mobilní prohlížeče mají jiné chování při posouvání a klávesnice může změnit rozměry. Zkuste si stránku otevřít na mobilu s vypnutým připojením – uvidíte, jak se chovají obrázky a text. Správně nastavený Grid a Flexbox by měly držet obsah čitelný i bez načtených fontů. Pokud se rozvržení rozpadne, je to obvykle tím, že jste použili pevnou šířku nebo zapomněli na min-width: 0 u Grid položek. Tuto vlastnost si zapamatujte – často řeší problémy s přetékajícím textem. Pokud projekt běží na více jazycích, vyplatí se také zavést kontrolní mechanismus. Než něco nasadíte do produkce, projeďte si všechny jazykové soubory a zkontrolujte, jestli mají stejný počet klíčů. Jeden chybějící klíč dokáže zobrazit technický název místo textu, což působí amatérsky. Stejně důležité je pravidelně odstraňovat mrtvé překlady – texty, které se už v aplikaci nepoužívají, ale v souboru zůstávají. Přibývají s každou změnou a po roce z nich máte nepořádek, kterému nikdo nerozumí. Jak poznáte, že je vaše pyramida postavená na písku Prvním krokem je revize stávající sady testů. Spočítejte si poměr mezi jednotkovými a end-to-end testy v projektu. Pokud dominují E2E, začněte je přesouvat na nižší úrovně — ale ne mechanicky. Většina byznys logiky se dá ověřit na úrovni jednotkových testů, zatímco E2E si nechte jen pro hlavní uživatelské cesty, jako je přihlášení nebo dokončení objednávky. Při přesouvání se zaměřte na to, co test opravdu ověřuje: jestli kontrolujete chování jedné třídy, je to unit test; jestli spolupracuje více modulů, je to integrační test. Nezapomínejte ani na přístupnost. Správné použití Gridu a Flexboxu neovlivňuje HTML strukturu, takže můžete mít logické pořadí nadpisů a odstavců a vizuálně je přeskupit. To je velká výhoda. Ale pozor – pokud používáte Grid k rozmístění prvků, které na sebe navazují v čtení, držte se stejného pořadí v HTML i vizuálně. Prohlížeče někdy při změně velikosti okna přepočítávají rozvržení pomaleji, takže pokud kombinujete hodně vnořených Gridů a Flexboxů, může to zamrznout. Držte se jednoduchosti: maximálně dvě úrovně vnoření. Začněte u informační hierarchie. Obrazovka by měla vést oko návštěvníka od nejdůležitějšího prvku k méně důležitým. Hlavní výzvu k akci (například tlačítko pro odeslání formuláře) umístěte do vizuálně exponovaného místa, obvykle do prvního pohledu. Nezahlcujte prostor desítkami barev a kontrastních prvků – pokud je všechno zvýrazněné, nic se nezvýrazní. Pro běžné akce používejte neutrální barvy, pro primární akci sytou, ale ne křiklavou. 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í. Akce by měly být co nejjednodušší a popisovat událost, ne co se má stát. Typická chyba je vytvářet akce typu SET_USER_AND_LOAD_ORDERS_AND_UPDATE_CART, které v sobě mísí více zodpovědností. Pak je těžké testovat a ladit. Místo toho rozdělte akce na malé, atomické – SET_USER, LOAD_ORDERS, UPDATE_CART. Reducer by měl být synchronní a neměl by provádět žádné vedlejší efekty, jako je volání API nebo zápis do lokálního úložiště. Tyto operace patří do middleware, nejlépe do Redux Thunk nebo Redux Toolkit. Pokud toto nerespektujete, dostanete se do stavů, kdy akce spouští jiné akce a vy ztrácíte přehled o toku dat. Samotná práce s překlady vyžaduje disciplínu, ne nástroj. Nejdůležitější je pravidlo, že do vět v kódu nikdy nevkládáte skloňované výrazy – pokud máte větu „Vítejte v našem obchodě", nerozdělíte ji na „Vítejte v" a „obchodě", protože v angličtině to pak nedává smysl. Místo toho uložíte celou větu jako jeden klíč a v každém jazyce ji napíšete od začátku. Stejně tak pozor na pořadí slov. Anglické „You have 3 new messages" nelze věrně přeložit do češtiny, pokud máte proměnnou na konci – proto vždy ukládejte celé fráze i s čísly nebo jmény. Při responzivním designu se vyhněte pevným hodnotám jako width: 300px. Místo toho používejte jednotky fr, %, auto, nebo minmax(). Například pro obsah s bočním panelem použijte grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)). Tím zajistíte, že se prvky samy přeskupí, když je obrazovka úzká. U Flexboxu zase hlídáte vlastnost flex-wrap. Pokud ji nenastavíte na wrap, prvky se budou zmenšovat, až se nevejdou. To je druhý nejčastější problém – prvky se mačkají místo toho, aby se posunuly do nového řádku.

User:NathanielMcReyno

2026-08-29T03:26:40Z

NathanielMcReyno: Created page with "Někdo, kdo praktickým bydlením žije už dlouho. Sdílím zde, jak zvládnout domácnost bez stresu. Nejvíc mě baví ukazovat chytrá řešení, která zvládne každý."

Někdo, kdo praktickým bydlením žije už dlouho. Sdílím zde, jak zvládnout domácnost bez stresu. Nejvíc mě baví ukazovat chytrá řešení, která zvládne každý.

Dusty Ways: Rebirth - User contributions [en]

Když chcete psát testy v Pythonu, vyzkoušejte pytest a vyhněte se chybám

User:NathanielMcReyno