it-swarm-eu.dev

Kolik pokrytí kódem je „dost“?

Začínáme Push pro pokrytí kódu tady v mé práci, a to mě přimělo k přemýšlení .... Kolik pokrytí kódu je dost?

Kdy se dostanete k bodu snižování návratnosti pokrytí kódem? Jaké je sladké místo mezi dobrým pokrytím a nedostatkem? Liší se to podle typu vašeho projektu (tj. WPF, WCF, Mobile, ASP.NET) (Jedná se o třídy C #, které píšeme.)

38
Vaccano

Naším cílem je alespoň 70%. Ve věcech, které jsou snadněji testovatelné (například funkční datové struktury), se zaměřujeme na 90% a většina jednotlivců se zaměřuje na co nejblíže 100%. U věcí souvisejících s WPF a dalších rámců, které je velmi obtížné otestovat, dostáváme mnohem nižší pokrytí (sotva 70%).

19
Noah Richards

Jsem toho názoru, že samotné pokrytí kódem je špatná metrika. Je snadné vyrobit tuny zbytečných testů, které cover kód, ale neprovádějí dostatečnou kontrolu výstupu nebo netestují například případy Edge. Krycí kód znamená, že nevyvolává výjimku, ne že má pravdu. Potřebujete kvalitní testy - množství není tak důležité.

55
Fishtoaster

„Dost“ je situace, kdy můžete s kódem provést změny s jistotou, že nic neporušujete. U některých projektů to může být 10%, u jiných to může být 95%.

Je téměř nikdy tak vysoko jako 100%. Někdy se však může pokusit získat 100% pokrytí kódem skvělým způsobem, jak odstranit nečistoty ze základny kódu. Nezapomeňte, že existují dva způsoby, jak zvýšit pokrytí kódu - napsat více testů nebo odebrat kód. Pokud kód není zahrnut, protože je obtížné jej otestovat, existuje dobrá šance, kterou můžete zjednodušit nebo změnit, aby bylo testování snadnější. Pokud je příliš obskurní na to, aby se obtěžovalo testovat, existuje obvykle dobrá šance, že ho v kódu nepoužívá nic jiného.

38
RevBingo

Pokrytí kódu se blíží 100% asymptoticky. V důsledku toho, že posledních 5% je pravděpodobně více úsilí, než stojí za to, protože za vynaložené úsilí začnete dosahovat marně malých výnosů.

14
Robert Harvey

Pokrytí je metrika , která sleduje, ale neměl by být konečným cílem. Viděl jsem (a samozřejmě jsem napsal!) Spoustu kódu s vysokým pokrytím - 100% pokrytí (samozřejmě TDD), přesto:

  • stále se objevují chyby
  • design může být stále špatný
  • můžete opravdu zabít střelbu na libovolný cíl pokrytí - vyberte své bitvy: p

Je tu „způsob testivus“ záznam , o kterém si myslím, že je vhodné odkazovat zde :)

7
H.Y.

Pouze 20% většiny kódu poběží 80% čas . Analýza pokrytí kódu není příliš užitečná, pokud není spárována s grafem volání k určení toho, co je třeba nejvíce testovat. To vám řekne, kde budou pravděpodobně vaše případy Edge. Můžete přijít se 100 testy jen pro ty případy Edge, které představují méně než 5% skutečného kódu.

Nezapomeňte tedy pokrýt 100% z 20%, které definují kritické cesty, a alespoň 50% zbytku (podle grafu volání). To by vám mělo (zhruba) 70% - 75% celkové krytí, ale liší se.

Nevypalujte čas a snažte se získat více než 70% celkového pokrytí, přičemž kritické případy Edge nechávejte bez kontrol.

5
Tim Post

Použijte pokrytí jako vodítko pro označení testovaných oblastí. Namísto toho, aby měl mandát pro pokrytí, je rozumnější pochopit důvod, proč kód není zahrnut. Zaznamenání důvodu nedostatku je dobrá disciplína, která umožňuje vyvážení rizik.

Někdy je důvod méně než žádoucí. došel čas “, ale může být v pořádku pro předčasné vydání. Je lepší označit oblasti, k nimž se později vracet, a zvýšit tak pokrytí.

Pracuji na softwaru pro kritické lety, kde je 100% pokrytí prohlášení považováno za vhodné pro nekritické systémy. U kritičtějších systémů zkontrolujeme pokrytí odvětví/rozhodnutí a použijeme techniku ​​volání MC/DC, která někdy není dostatečně přísná.

Musíme se také ujistit, že jsme také zahrnuli kód objektu.

Je to rovnováha mezi rizikem, v našem případě velmi vysokým, proti hodnotě/náklady. Je zapotřebí informovaná volba na základě rizika, že chybí chyba.

4
Mark Fisher

Když začnete uvažovat o změnách, které by ovlivnily výkon běhu, zabezpečení, flexibilitu nebo udržovatelnost a umožnily větší pokrytí kódem, je čas ukončit hledání většího pokrytí kódem.

Mám projekty, kde je tento bod 0%, protože pokrytí nelze vypočítat, aniž by došlo k poškození designu a dalších projektů, kde je to až 92%.

Metriky kódového pokrytí jsou užitečné pouze při poukazování na případy, že byste mohli vynechat některé testy. Neříká vám nic o kvalitě vašich testů.

3
Bill

Opravdu se mi líbí odpověď @ RevBingo, protože navrhuje, že boj o 100% může způsobit, že vyčistíte nebo odstraníte nepoužitý kód. To, co jsem v ostatních odpovědích neviděl, je pocit, kdy potřebujete vysoké pokrytí a kdy ne. Začal jsem to bodnout. Myslím, že přidání podrobností do grafu, jako je tento, by bylo užitečnější pronásledování než nalezení jednoho čísla testovacího pokrytí, které by bylo vhodné pro všechny kódy.

100%

U veřejných API, jako jsou kolekce Java.util, které nejsou propojeny s databází a nevrací HTML, si myslím, že 100% pokrytí je ušlechtilým výchozím cílem, i když se spokojíte s 90-95% kvůli času nebo jinému omezení. Zvyšující se pokrytí testu po dokončení funkce vynutí podrobnější úroveň kontroly než jiné druhy kontroly kódu. Pokud je vaše API vůbec populární, lidé jej budou používat, podtřídou, deserializací atd. Způsobem, který nelze očekávat. Nechcete, aby jejich první zkušenost byla nalezením chyby nebo dohledu nad designem!

90%

V případě kódu obchodní infrastruktury, který přijímá datové struktury a vrací datové struktury, je 100% pravděpodobně dobrým výchozím cílem, ale pokud tento kód není dostatečně veřejný, aby pozval hodně zneužití, možná 85% je stále přijatelné?

75%

U kódu, který přijímá a vrací řetězce, si myslím, že testování jednotek je mnohem křehčí, ale v mnoha situacích může být stále užitečné.

50% nebo méně

Nesnáším psaní testů na funkce, které vracejí HTML, protože je tak křehké. Co když někdo změní CSS, JavaScript nebo celý blok HTML a angličtiny, který vrátíte, nedává lidským koncovým uživatelům smysl? Pokud najdete funkci, která používá hodně obchodní logiky k vytvoření malého HTML, může se vyplatit testování. Ale obrácená situace nemusí být vůbec testovací.

Téměř 0%

U některých kódů má definice „správný“ smysl „pro koncového uživatele“. Proti tomuto kódu můžete provádět netradiční testy, jako je automatická kontrola gramatiky nebo HTML ověření výstupu. Dokonce jsem nastavil grep prohlášení pro malé nekonzistence, které běžně upadáme do práce, jako když řekneme „Přihlášení“, když to zbytek systému nazývá „Přihlásit“. Tento muž nemusí být přísně testem jednotky, ale užitečným způsobem, jak zachytit problémy, aniž by očekával konkrétní výstup.

Nakonec však jen člověk může posoudit, co je pro člověka rozumné. Testování jednotek vám tam nemůže pomoci. Někdy trvá několik lidí, aby to přesně posoudili.

Absolutní 0%

Toto je smutná kategorie a já se cítím jako méně člověk, který ji napíše. Ale v jakémkoli dostatečně velkém projektu jsou králičí díry, které mohou sát osobu týdně bez poskytnutí jakýchkoli obchodních výhod.

Koupil jsem si knihu, protože tvrdil, že ukazuje, jak automaticky zesměšňovat data pro testování režimu spánku. Testoval však pouze dotazy Hibernate HQL a SQL. Pokud musíte udělat hodně HQL a SQL, nemáte výhodu Hibernate opravdu dost. Existuje určitá forma databáze Hibernace v paměti, ale neinvestoval jsem čas, abych zjistil, jak ji efektivně využít v testech. Kdybych měl tento běh, chtěl bych mít vysoké (50% - 100%) zkušební pokrytí pro každou obchodní logiku, která počítá věci pomocí navigace v grafu objektů, což způsobí, že Hibernate spouští některé dotazy. Moje schopnost vyzkoušet tento kód je v současné době téměř 0% a to je problém. Takže vylepšuji pokrytí testů v jiných oblastech projektu a snažím se upřednostňovat čistě funkce před těmi, které přistupují k databázi, hlavně proto, že je jednodušší psát testy pro tyto funkce. Přesto některé věci nelze nebo neměly být testovány.

2
GlenPeterson

Prostorový software vyžaduje 100% pokrytí výkazu.

Zpočátku to nedává smysl. Každý ví, že úplné testovací pokrytí neznamená, že je kód plně testován a že není tak obtížné získat 100% pokrytí bez skutečného testování aplikace.

Přesto je 100% pokrytí nižší limit: ačkoli 100% pokrytí není důkazem bezchybného softwaru, je jisté, že s menším pokrytím není kód plně testován, a to je prostě nepřijatelné pro kosmický software.

2
mouviciel

Myslím, že to záleží na části aplikace, kterou testujete. Např. Pokud jde o obchodní logiku nebo jakoukoli složku zahrnující komplexní transformaci dat, zaměřil bych se na 90% (co nejvyšší) pokrytí. Často jsem našel malé, ale nebezpečné chyby pouhým testováním co největší části kódu, jak je to možné. Raději bych takové chyby našel během testování než nechat je vyskytnout se na místě zákazníka o rok později. Výhodou vysokého pokrytí kódu je také to, že brání lidem v tom, aby změnili pracovní kód příliš snadno, protože testy musí být odpovídajícím způsobem upraveny.

Na druhé straně si myslím, že existují komponenty, pro které je pokrytí kódu méně vhodné. Například při testování GUI je velmi časově náročné napsat test, který pokryje veškerý kód, který se spustí po kliknutí na tlačítko, aby se událost poslala do správných komponent. Myslím, že v tomto případě je mnohem efektivnější použít tradiční postup provedení manuálního testu, ve kterém stačí kliknout na tlačítko a sledovat chování programu (otevře se pravé dialogové okno? Otevře se ten správný nástroj? ?).

1
Giorgio

Nemám tak vysoký názor na používání pokrytí kódem jako měřítka pro zjištění, kdy má vaše testovací sada dostatečné pokrytí.

Hlavním důvodem je to proto, že pokud máte proces, ve kterém nejprve napíšete nějaký kód, pak některé testy a poté se podíváte na pokrytí kódu, abyste zjistili, kde jste vynechal test, pak je to proces, který je třeba zlepšit. Pokud opravdově TDD, máte pokrytí kódem 100% po vybalení z krabice (je pravda, že existují některé drobnosti, které netestuji). Pokud se ale podíváte na pokrytí kódem a zjistíte, co chcete testovat, pravděpodobně budete psát nesprávné testy.

Jedinou věcí, kterou můžete z pokrytí kódu vyvodit, je, že pokud je příliš nízká, nemáte dostatek testů. Pokud je však vysoká, neexistuje záruka, že máte všechny správné testy.

0
Pete