• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Častou chybou bývá, že někdo commitne rovnou do hlavní větve. Tím se snadno rozbije stabilní verze a ostatní si stáhnou rozbitý kód. Řešením je zakázat přímé commity do hlavní větve a vyžadovat, aby každá změna prošla pull requestem (nebo merge requestem, podle toho, jakou službu používáte). Pull request umožňuje ostatním prohlédnout si změny, If you loved this informative article and you would love to receive more information regarding Http://orasch.com/index.php?Title=jak_využít_es6_naplno:_tipy_pro_moderní_javascript please visit our web site. okomentovat je a teprve potom je sloučit. Můžete si také nastavit, že je nutná alespoň jedna schválená recenze od jiného člena týmu. Tím se výrazně snižuje riziko, že se do hlavní větve dostane chyba.

V praxi se vyplatí sledovat i trend pokrytí v čase, nejen aktuální hodnotu. Pokud pokrytí roste, ale počet bugů neklesá, je něco špatně. Možná testujete špatné věci, nebo máte testy, které jsou závislé na datech a neodhalují skutečné problémy. V takovém případě je lepší investovat čas do revize testů a odstranění těch, které nepřinášejí hodnotu, než zvyšovat číslo. Někdy je totiž lepší mít 70% pokrytí s kvalitními testy než 90% pokrytí s hromadou bezcenných testů, které jen zpomalují build a zvyšují náklady na údržbu.

Pro měření se používají nástroje, které sledují běh testů a generují reporty. V moderních jazycích je integrace obvykle triviální – stačí přidat závislost a spustit testy s příslušným profilem. Nezapomeňte ale, že pokrytí se vztahuje k tomu, jaké testy spouštíte. Pokud používáte jen unit testy, uvidíte pokrytí pouze v rámci testovaných tříd. Pro celkový obrázek je potřeba zapojit i integrační testy a měřit pokrytí při jejich běhu. Typická chyba je měřit pokrytí jen na jednom profilu a pak z toho dělat univerzální závěry.

Kdy už je pokrytí spíše číslo než užitek Pokrytí přestává být užitečné ve chvíli, kdy začnete psát testy jen proto, aby číslo vzrostlo. Typický příklad je test, který zavolá metodu, ale neověří žádný výstup, nebo dokonce testy, které kontrolují pouze to, že se metoda nedostane do výjimky. Takové testy sice zvyšují procento pokrytí, ale nedávají žádnou záruku, že kód funguje správně. Dalším varovným signálem je, když se začnete vyhýbat psaní testů pro složité části kódu a místo toho testujete jen triviální gettry a settery. Tím pokrytí roste, ale reálná ochrana před chybami zůstává stejná.

Typickou chybou, kterou dělá nejeden vývojář, je zapomínání na malé commity s nesrozumitelnými zprávami. Každý commit by měl být samostatnou, funkční jednotkou a jeho zpráva by měla jasně popisovat, co a proč mění. Vyvarujte se větám jako „oprava" nebo „úpravy" – místo toho pište „oprava výpočtu ceny při slevě" nebo „refaktoring validace e-mailu". Tato disciplína se vám vrátí při hledání chyb i při code review.

Hranice, kdy pokrytí ztrácí smysl, není univerzální. Obecně platí, že pod 60 % je kód pravděpodobně nedostatečně otestovaný, ale nad 90 % už začínáte platit daň v podobě údržby testů, které často jen zrcadlí implementaci bez ohledu na chování. Neexistuje žádné magické číslo, které by bylo správné pro všechny projekty. Důležitější než samotné procento je to, co testy skutečně ověřují. Pokud máte 80% pokrytí a testy hlídají klíčové business scénáře, je to lepší než 95% pokrytí bez jediného smysluplného assertu.

Začít používat git ve větším týmu bez jasných pravidel je jako pustit pět lidí do stejného dokumentu bez verzí. Každý dělá co uzná za vhodné, větve rostou do všech stran a merge končí konfliktem, který nikdo nechce řešit. Přitom stačí dodržovat pár základních principů, které týmovou práci zjednoduší a hlavně zrychlí.

Dalším osvědčeným postupem je rozdělení práce na menší, logické celky. Každá feature větev by měla řešit jeden konkrétní úkol, ať už jde o opravu bugu, přidání funkce nebo refaktoring. Do větve nepatří nesouvisející změny, byť by byly sebemenší. Pokud potřebujete upravit něco, co s úkolem nesouvisí, vytvořte si na to samostatnou větev. Tím zajistíte, že každý commit je snadno revertovatelný a historie větve zůstává čitelná.

Základní pravidla pro větve a commity Nejdůležitější je domluvit se na tom, jak zařídit malou kuchyni budou větve vypadat. Nejčastěji se používá model, kde hlavní větev (nejčastěji master nebo main) obsahuje pouze stabilní a otestovaný kód. Veškerý vývoj probíhá na samostatných větvích, které se pojmenovávají podle úkolu, například feature/login-page nebo bugfix/oprava-prihlaseni. Každá větev by měla být krátká a měla by řešit jen jeden problém. Pokud pracujete na více věcech najednou, rozdělte si práci na menší úkoly a pro každý vytvořte samostatnou větev. Méně změn v jedné větvi znamená méně konfliktů při slučování.