Nakonec si osvojte pravidlo čisté historie. Před odesláním pull requestu si projděte své commity a případně je slučte do menšího počtu logických celků. Tím usnadníte práci nejen sobě, ale i kolegům, kteří budou váš kód kontrolovat. Pokud používáte interaktivní rebase, dejte pozor na to, abyste nepřepsali historii větve, na které už někdo jiný staví. Sdílené větve je lepší nesquashovat silou, ale raději vytvořit novou čistou větev a starou smazat. Tím předejdete zmatkům a ztraceným commitům, které by vedly k nekonzistentnímu stavu repozitáře.<br>
<br>
<br>
<br>
Pátá zásada se týká komunikace odhadu. Odhad nikdy nepředkládejte jako jistotu. Řekněte: „Předpokládám, že to bude do dvou týdnů, ale může to trvat až tři." Tím dáte zadavateli jasný obrázek a zároveň si necháte prostor pro manévrování. Zároveň se vyhněte tomu, abyste odhad snižovali kvůli tlaku okolí. Pokud vedení požaduje rychlejší termín bez změny rozsahu, je to jeho rozhodnutí – vy ale musíte jasně říct, jaká jsou rizika. Dobrý odhad není ten, který potěší, ale ten, který odpovídá realitě.<br>
<br>
<br>
<br>
Čtvrtý princip se týká historických dat. Pokud vedete záznamy o tom, jak dlouho trvaly předchozí úkoly, použijte je pro budoucí odhady. Pokud podobná funkce minule zabrala 14 dní, je nepravděpodobné, že tentokrát bude hotová za 3 dny, pokud se zásadně nezměnil tým nebo postup. Sbírejte data průběžně – po dokončení úkolu si poznamenejte skutečný čas, ne jen plánovaný. Po několika projektech uvidíte své vlastní vzorce: kde se obvykle zpožďujete, co podceňujete a co naopak přeceňujete. Tyto poznatky jsou cennější než jakýkoli obecný vzorec.<br>
<br>
<br>
<br>
Verzování kódu při práci na více feature větvích se snadno zvrtne v chaotický slepence commitů, merge konfliktů a ztracených změn. Základní pravidlo, které drží projekty nad vodou, zní: každá větev by měla být krátkodobá, úzce zaměřená a pravidelně synchronizovaná s hlavní větví. Čím déle větev žije odděleně, tím větší je pravděpodobnost, že se při sloučení střetnou nekompatibilní změny. Doporučuji proto rozdělit velké úkoly na menší části a každou z nich řešit v samostatné větvi, kterou po dokončení okamžitě začleníte.<br>
<br>
<br>
<br>
První praktické kroky, které nahradí chybějící zkušenosti Začněte u vlastního prostředí. Vyberte si běžnou webovou aplikaci, kterou používáte denně, a začněte ji testovat systematicky. Vytvořte si jednoduchou tabulku, kam si budete zapisovat jednotlivé testovací scénáře, kroky, očekávané výsledky a skutečné chování. Zkuste se zaměřit na okrajové případy, prázdná pole, nezvyklé délky textu nebo opakované odeslání formuláře. Tento vlastní projekt je vaším portfoliem, které můžete ukázat u pohovoru.<br>
<br>
<br>
<br>
Co nejčastěji zkazí začátečníci a jak se tomu vyhnout Častým omylem je snaha otestovat všechno najednou. Místo toho si zvolte jednu malou oblast – třeba přihlašovací formulář – a věnujte se jí důkladně. Zkuste různé kombinace vstupů: prázdné pole, příliš dlouhý řetězec, diakritiku nebo neplatný e-mail. Zapisujte si každý test, ať už skončil úspěchem, nebo chybou. To ukáže vaši pečlivost a systematičnost.<br>
<br>
<br>
<br>
Nejdůležitější je pochopit, jak pytest spouští jednotlivé testy. Spuštění provedete příkazem pytest v adresáři s testy. Pytest sám prohledá aktuální složku a podsložky a najde soubory odpovídající konvenci. Když chcete spustit jen jeden soubor, napíšete pytest test_math.py. Pro konkrétní test použijete pytest test_math.py::test_plus. Tento zápis je užitečný, když máte mnoho testů a chcete rychle ověřit jeden z nich.<br>
<br>
<br>
<br>
Než začnete s pytestem, ujistěte se, že máte nainstalovanou aktuální verzi knihovny. Nejjednodušší je použít pip, ale pokud používáte virtuální prostředí, přejděte do něj a teprve poté proveďte instalaci. Soubory s testy pojmenujte tak, aby začínaly na test_ (např. test_math.py) nebo končily na _test.py. Stejně tak funkce – každá testovací funkce musí začínat slovem test. Pokud toto pravidlo nedodržíte, pytest nepozná, že se jedná o test, a vy pak nevíte, proč se nic nespustilo.<br>
<br>
<br>
<br>
Typické chyby, které ztěžují zpětnou dohledatelnost Nejčastějším prohřeškem je vágnost. Zpráva „Změny v souboru" neříká nic o tom, co změna dělá. Stejně zrádné jsou i zprávy sice konkrétní, ale psané v minulém čase, které popisují, co už bylo hotovo, místo toho, co commit přináší. Rozdíl mezi „Opravena chyba v přihlášení" a „Oprav přihlášení při prázdném heslu" je zásadní – druhá varianta jasně říká, kdy a kde problém nastane. Další častou chybou je přidávání nesouvisejících změn do jednoho commitu, což znemožňuje rychlé pochopení logiky a komplikuje reverty.
