it-swarm-eu.dev

Stojí Unit Testing za to úsilí?

Pracuji na integraci testování jednotek do vývojového procesu v týmu, na kterém pracuji, a existuje několik skeptiků. Jaké jsou dobré způsoby, jak přesvědčit skeptické vývojáře o hodnotě jednotkového testování? V mém konkrétním případě bychom přidávali Unit Testy, protože přidáváme funkčnost nebo opravené chyby. Naše kódová základna bohužel neumožňuje snadné testování.

573
Ross Fuhrman

Každý den v naší kanceláři probíhá výměna, která vypadá takto:

"Člověče, miluji jen testy jednotek, právě jsem dokázal provést spoustu změn ve způsobu, jakým něco funguje, a pak jsem byl schopen potvrdit, že jsem nic neporazil opakováním testu ..."

Podrobnosti se mění každý den, ale sentiment se nemění. Jednotkové testy a vývoj řízený testem (TDD) mají tolik skrytých a osobních výhod, stejně jako ty zjevné, které vám někdo opravdu nedokáže vysvětlit, dokud to sami neučiní.

Ale ignoruji to, tady je můj pokus!

  1. Testy jednotek umožňují rychlé změny kódu. Víte, že to funguje nyní, protože jste provedli testy, když provedete změny, které musíte provést, musíte testy znovu uvést do provozu. To šetří hodiny.

  2. TDD vám pomůže uvědomit si, kdy ukončit kódování. Vaše testy vám dávají jistotu, že jste prozatím udělali dost, a mohou přestat vyladit a přejít k další věci.

  3. Testy a kód spolupracují na dosažení lepšího kódu. Váš kód může být špatný/buggy. Váš TEST může být špatný/buggy. V TDD bankujete s pravděpodobností, že obojí špatné/buggy nízké. Často je to test, který vyžaduje opravu, ale to je stále dobrý výsledek.

  4. TDD pomáhá při zácpě při kódování. Když budete čelit velké a skličující práci před psaním testů, dostanete se rychle do pohybu.

  5. Testy jednotek vám pomohou skutečně porozumět designu kódu, na kterém pracujete. Místo toho, abyste psali kód, abyste něco udělali, začínáte tím, že nastíníte všechny podmínky, kterým je kód vystaven, a jaké výstupy od toho očekáváte.

  6. Testy jednotek vám poskytují okamžitou vizuální zpětnou vazbu, všichni jsme rádi pocit všech těch zelených světel, když jsme to udělali. Je to velmi uspokojivé. Je také mnohem snazší vyzvednout si, kde jste přestali po přerušení, protože vidíte, kam jste se dostali - další červené světlo, které potřebuje opravit.

  7. Na rozdíl od všeobecného vyznání víry jednotka neznamená psaní dvakrát tolik kódu, nebo kódování pomaleji. Je to rychlejší a robustnější než kódování bez testů, jakmile to zvládnete. Samotný testovací kód je obvykle relativně triviální a nepřispívá k tomu, co děláte, velkou režii. Tohle budeš věřit jen tehdy, když to děláš :)

  8. Myslím, že to byl Fowler, kdo řekl: „Nedokonalé testy, které probíhají často, jsou mnohem lepší než perfektní testy, které se nikdy nepíšou“. Interpretuji to tak, že mi dovoluji psát testy, kde si myslím, že budou nejužitečnější, i když zbytek mého pokrytí kódem je žalostně neúplný.

  9. Dobré jednotkové testy mohou pomoci dokumentovat a definovat, co má něco dělat

  10. Jednotkové testy pomáhají s opakovaným použitím kódu. Migrujte svůj kód a vaše testy do nového projektu. Vylaďte kód, dokud se testy neběží znovu.

Hodně práce, se kterou se zabývám, se netestuje dobře Unit Unit (interakce s uživateli webových aplikací atd.), Ale přesto jsme všichni testováni v tomto obchodě infikovaní a nejšťastnější, když máme testy svázané. Nemohu doporučit přístup dostatečně vysoko.

722
reefnet_alex

Testování jednotek je hodně jako chodit do tělocvičny. Víte, že je to pro vás dobré, všechny argumenty dávají smysl, takže začnete cvičit. Je tu počáteční Rush, což je skvělé, ale po několika dnech se začnete ptát, jestli to stojí za to. Berete hodinu ze dne na to, abyste si vyměnili šaty a běhali na křečkovitém kole a nejste si jisti, že opravdu něco získáváte, jen bolest v nohou a pažích.

Poté, možná po jednom nebo dvou týdnech, právě jak bolest ustupuje, se začíná blížit Velká lhůta. Musíte strávit každou hodinu probuzení a pokusit se udělat „užitečnou“ práci, takže vyříznete cizí věci, jako byste chodili do posilovny. Vypadáte ze zvyku a v době, kdy skončí Velká lhůta, jste zpět na druhou. Pokud se vám podaří vrátit se do tělocvičny vůbec, cítíte se stejně bolestně jako jste byli poprvé, kdy jste šli.

Děláte nějaké čtení, abyste zjistili, zda děláte něco špatně. Začnete cítit trochu iracionální navzdory všem fit, šťastní lidé vychvalovat ctnosti cvičení. Uvědomujete si, že nemáte mnoho společného. Nemusejí jezdit 15 minut z cesty do posilovny; v jejich budově je jeden. Nemusí se s nikým hádat o výhodách cvičení; je to něco, co každý dělá a přijímá jako důležité. Když se blíží Big Deadline, není jim řečeno, že cvičení je zbytečné, než by vás šéf požádal, abyste přestali jíst.

Takže, abyste odpověděli na vaši otázku, testování jednotky obvykle stojí za námahu, ale požadované úsilí nemusí být stejné pro všechny. Testování jednotek může vyžadovat obrovské úsilí, pokud se zabývají základnou kódu špaget ve společnosti, která nemá ve skutečnosti hodnotu kódu kvality. (Mnoho manažerů bude zpívat chválení Unit Testingu, ale to neznamená, že se na to budou držet, až na tom záleží.)

Pokud se pokoušíte představit Unit Testing do své práce a nevidíte všechny sluneční paprsky a duhy, které jste byli vedeni očekávat, neobviňujte se. Možná budete muset najít novou práci, aby vám testování jednotky skutečně fungovalo.

421
benzado

Nejlepší způsob, jak přesvědčit ... najít chybu, napsat test jednotky, opravit chybu.

Tato konkrétní chyba se pravděpodobně nikdy neobjeví znovu a můžete to dokázat pomocí svého testu.

Pokud to uděláte dost, ostatní se rychle chytí.

136
Ed Guiness

thetalkingwalnut se ptá:

Jaké jsou dobré způsoby, jak přesvědčit skeptické vývojáře o hodnotě jednotkového testování?

Všichni zde budou hromadit z mnoha důvodů, proč je testování jednotky dobré. Zjistil jsem však, že často nejlepším způsobem, jak někoho přesvědčit, je poslouchat jejich argumentu a adresovat ho bod po bodu. Pokud jim nasloucháte a pomáháte jim verbalizovat jejich obavy, můžete oslovit každý z nich a možná je převést do svého úhlu pohledu (nebo přinejmenším nechat bez nohy, aby se postavili). Kdo ví? Možná vás přesvědčí, proč testy jednotek nejsou pro vaši situaci vhodné. Není pravděpodobné, ale možné. Možná, pokud zveřejníte své argumenty proti jednotkovým testům, můžeme vám pomoci identifikovat protiopatření.

Je důležité naslouchat a pochopit obě strany argumentu. Pokud se pokusíte přijmout jednotkové testy příliš horlivě bez ohledu na obavy lidí, skončíte náboženskou válkou (a pravděpodobně opravdu bezcennými jednotkovými testy). Pokud ji přijmete pomalu a začnete ji používat tam, kde uvidíte největší přínos za co nejnižší náklady, můžete prokázat hodnotu jednotkových testů a mít větší šanci přesvědčit lidi. Uvědomuji si, že to není tak snadné, jak to zní - obvykle vyžaduje nějaký čas a pečlivé metriky, aby vytvořily přesvědčivý argument.

Jednotkové testy jsou nástrojem, jako každý jiný, a měly by být aplikovány tak, aby přínosy (chycení chyb) převažovaly nad náklady (snaha je psát). Nepoužívejte je, pokud/kde to nedává smysl, a pamatujte si, že jsou pouze součástí vašeho arzenálu nástrojů (např. Inspekce, tvrzení, analyzátory kódu, formální metody atd.). Mojím vývojářům říkám toto:

  1. Mohou přeskočit psaní testu pro metodu, pokud mají dobrý argument, proč to není nutné (např. Příliš jednoduché, aby to stálo za to, nebo příliš obtížné, aby to stálo za to) a jak bude metoda jinak ověřena (např. Kontrola, tvrzení , formální metody, interaktivní/integrační testy). Musí vzít v úvahu, že některá ověření, jako jsou inspekce a formální důkazy, se provádějí v určitém okamžiku a poté je třeba je opakovat pokaždé, když se změní výrobní kód, zatímco jednotkové testy a tvrzení lze použít jako regresní testy (jednou psané a poté opakované) ). Někdy s nimi souhlasím, ale častěji budu diskutovat o tom, zda je metoda opravdu příliš jednoduchá nebo příliš obtížná na jednotkový test.

    • Pokud vývojář tvrdí, že metoda se zdá být příliš jednoduchá na to, aby selhala, nestojí za to vzít si 60 sekund potřebných k napsání jednoduchého testu na 5 řádků? Těchto 5 řádků kódu se bude spouštět každou noc (děláte noční sestavení, že?) Pro příští rok nebo více a bude to stát za námahu, i když se stane, že jednou chytí problém, který může trvat 15 minut nebo déle, než se identifikuje a ladění. Kromě toho, psaní jednoduchých testů jednotek zvyšuje počet testů jednotek, což vývojáři vypadá dobře.

    • Na druhou stranu, pokud vývojář tvrdí, že metoda se zdá příliš obtížná pro jednotkový test (nestojí za to, že je třeba vynaložit značné úsilí), možná je to dobrý náznak, že metoda musí být rozdělena nebo refaktorizována pro testování snadných částí. Obvykle se jedná o metody, které se spoléhají na neobvyklé zdroje, jako jsou singletony, aktuální čas, nebo externí zdroje, jako je sada výsledků databáze. Tyto metody se obvykle musí refaktorizovat na metodu, která získá zdroj (např. Volá getTime ()) a metodu, která vezme zdroj jako argument (např. Vezme časové razítko jako parametr). Nechám je přeskočit testování metody, která načte zdroj, a místo toho píšou test jednotky pro metodu, která nyní bere zdroj jako argument. Obvykle to dělá psaní testu jednotky mnohem jednodušší, a proto stojí za to napsat.

  2. Vývojář musí nakreslit „čáru v písku“, jak komplexní by měly být jejich jednotkové testy. Později ve vývoji, kdykoli najdeme chybu, měli by zjistit, zda by problém vyřešily komplexnější testy jednotek. Pokud ano, a pokud se takové chyby objevují opakovaně, musí přesunout „linii“ směrem k psaní komplexnějších testů jednotek v budoucnosti (počínaje přidáním nebo rozšířením testu jednotky pro aktuální chybu). Potřebují najít správnou rovnováhu.

Je důležité si uvědomit, že jednotkové testy nejsou stříbrné kulky a tam je něco jako příliš mnoho jednotkových zkoušek. Na mém pracovišti, kdykoli učíme ponaučení, nevyhnutelně uslyším „potřebujeme napsat více jednotkových testů“. Vedení souhlasně přikývne, protože bylo narazeno do jejich hlav, že „testy jednotek“ == „dobré“.

Musíme však pochopit dopad „více jednotkových testů“. Vývojář umí psát pouze ~ N řádků kódu za týden a je třeba zjistit, jaké procento tohoto kódu by měl být kód testu jednotky vs výrobní kód. Laxní pracoviště může mít 10% kódu jako jednotkové testy a 90% kódu jako produkčního kódu, což má za následek produkt se spoustou (i když velmi buggy) funkcí (myslím MS Word). Na druhé straně, přísná prodejna s 90% jednotkovými testy a 10% výrobním kódem bude mít pevný produkt s velmi malými vlastnostmi (myslím „vi“). Možná nikdy neslyšíte zprávy o havárii posledně uvedeného produktu, ale to pravděpodobně má co do činění s produktem, který se příliš dobře neprodává, stejně jako s kvalitou kódu.

Ještě horší je, že jedinou jistotou ve vývoji softwaru je to, že „změna je nevyhnutelná“. Předpokládejme, že přísný obchod (90% jednotkových testů/10% výrobní kód) vytváří produkt, který má přesně 2 funkce (za předpokladu, že 5% výrobního kódu == 1 funkce). Pokud zákazník přijde a změní 1 funkce, změní se trashes 50% kódu (45% jednotkových testů a 5% výrobního kódu). Lax shop (10% jednotkových testů/90% výrobní kód) má produkt s 18 vlastnostmi, z nichž žádný nefunguje velmi dobře. Jejich zákazník zcela přepracovává požadavky na 4 své funkce. I když je změna čtyřikrát větší, pouze polovina kódu se dostane do koše (~ 25% = ~ 4,4% jednotkových testů + 20% výrobního kódu).

Chci říci, že musíte sdělit, že rozumíte té rovnováze mezi příliš malým a příliš velkým testováním jednotek - v podstatě jste mysleli přes obě strany problému. Pokud můžete přesvědčit své vrstevníky a/nebo jejich správu, získáte důvěryhodnost a možná budete mít větší šanci je získat.

69
Bert F

Mnohokrát jsem si pohrával s jednotkovým testováním a stále musím být přesvědčen, že to stojí za námahu vzhledem k mé situaci.

Vyvíjím webové stránky, kde velká část logiky zahrnuje vytváření, načítání nebo aktualizaci dat v databázi. Když jsem se pokusil "zesměšňovat" databázi pro účely testování jednotek, dostal se velmi chaotický a vypadal trochu zbytečně.

Když jsem napsal obchodní testy týkající se obchodní logiky, nikdy mi to z dlouhodobého hlediska opravdu nepomohlo. Protože do značné míry pracuji na projektech, mám sklon intuitivně vědět, na kterých oblastech kódu může být něco, na čem pracuji, ovlivněno a tyto oblasti testuji ručně. Chci doručit řešení svému klientovi co nejrychleji a testování jednotek se často jeví jako ztráta času. Vypisuji manuální testy a procházím je skrz sebe, když je jdu, zaškrtněte je.

Vidím, že to může být výhodné, když tým vývojářů pracuje na projektu a aktualizuje si navzájem kód, ale i pak si myslím, že pokud jsou vývojáři vysoce kvalitní, měla by stačit dobrá komunikace a dobře napsaný kód .

38
Ronnie

Jedna skvělá věc na jednotkových testech je, že slouží jako dokumentace toho, jak se má váš kód chovat. Dobré testy jsou jako implementace referencí a spoluhráči se na ně mohou podívat, jak integrovat svůj kód s vašimi.

31
pkaeding

Testování jednotek stojí za počáteční investici. Od doby, kdy jsem před pár lety začal používat testování jednotek, jsem našel některé skutečné výhody:

  • regresní testování odstraňuje strach z provádění změn v kódu (není nic jako teplá záře vidění práce kódu nebo exploze při každé změně)
  • příklady spustitelného kód pro ostatní členy týmu (a sami za šest měsíců ...)
  • nemilosrdný refactoring - to je neuvěřitelně obohacující, zkuste to!

Úryvky kódu mohou být velkou pomocí při snižování režie vytváření testů. Není obtížné vytvářet úryvky, které umožňují vytvoření osnovy třídy a přidruženého testovacího zařízení za několik sekund.

26
Jonathan Webb

Měli byste otestovat co nejméně!

což znamená, že byste měli napsat tolik jednotkových testů, abyste odhalili záměr. To se často leskne. Jednotkové testování vás stojí. Pokud provedete změny a budete muset změnit testy, budete méně pohybliví. Mějte jednotkové testy krátké a sladké. Pak mají velkou hodnotu.

Příliš často vidím spoustu testů, které se nikdy nezlomí, jsou velké a nemotorné a nenabízejí mnoho hodnot, jen vás nakonec zpomalí.

25
Keith Nicholas

Neviděl jsem to v žádné z dalších odpovědí, ale jedna věc, kterou jsem si všiml, je, že mohl jsem ladit mnohem rychleji. K tomu, abyste se dostali ke kódu, který opravujete, nemusíte procházet svou aplikaci pouhým správným sledem kroků, pouze abyste zjistili, že jste udělali logickou chybu, a musíte to udělat znovu. Pomocí testu jednotky můžete přímo vstoupit do kódu, který ladíte.

23
John MacIntyre

[Mám smysl, abych to neviděl výše]

"Každý test jednotky, nemusí to nutně uvědomit - FACT"

Přemýšlejte o tom, že napíšete funkci, která může analyzovat řetězec a odstranit nové řádkové znaky. Jako vývojář nováčků skrze něj z příkazové řádky spustíte několik případů implementací do Main (), nebo vyhodíte dohromady vizuální rozhraní s tlačítkem, spojíte svou funkci s několika textovými poli a tlačítkem a uvidíte co se stalo.

Jedná se o testování jednotek - základní a špatně sestavené, ale část kódu vyzkoušíte v několika případech.

Píšete něco složitějšího. Vyhodí chyby, když zahodíte několik případů (testování jednotek) a vy ladíte kód a sledujete i když. Při procházení hodnotami se rozhodujete, zda jsou správné nebo nesprávné. Toto je do určité míry testování jednotky.

Jednotkové testování zde toto chování skutečně bere, formalizuje do strukturovaného vzoru a uloží, abyste je mohli snadno znovu spustit. Pokud napíšete „správný“ testovací případ jednotky, nikoli manuální testování, zabere to stejné množství času nebo možná méně času, než se dozvíte, a máte k dispozici opakování znovu a znovu

21
Chris Gill

Celé roky jsem se snažil lidi přesvědčit, že potřebovali napsat test jednotky pro svůj kód. Ať už testy nejprve napsali (jako v TDD) nebo poté, co zakódovali funkčnost, vždy jsem se jim snažil vysvětlit všechny výhody plynoucí z testování jednotek na kód. Málokdo se mnou nesouhlasil. Nemůžete nesouhlasit s něčím, co je zřejmé, a každý chytrý člověk uvidí výhody testu jednotky a TDD.

Problém při testování jednotek je v tom, že vyžaduje změnu chování a je velmi obtížné změnit chování lidí. Prostřednictvím slov získáte mnoho lidí, aby s vámi souhlasili, ale neuvidíte mnoho změn ve způsobu, jakým dělají věci.

Musíte přesvědčit lidi tím, že děláte. Váš osobní úspěch zaujme více lidí než všechny argumenty, které můžete mít. Pokud uvidí, že nemluvíte jen o testu jednotky nebo TDD, ale děláte to, co kážete, a jste úspěšní, lidé se vás pokusí napodobit.

Měli byste také převzít vedoucí roli, protože nikdo nenapisuje test jednotky poprvé, takže je možná budete muset trénovat, jak to udělat, ukázat jim cestu a dostupné nástroje. Pomozte jim při psaní prvních testů, přezkoumejte testy, které píšou sami, a ukažte jim triky, idiomy a vzorce, které jste se naučili prostřednictvím svých vlastních zkušeností. Po chvíli začnou vidět výhody samy o sobě a změní své chování tak, aby začlenily testy jednotek nebo TDD do svých nástrojů.

Změny se nestanou přes noc, ale s trochou trpělivosti můžete dosáhnout svého cíle.

16
Curro

Hlavní součástí vývoje řízeného testem, který je často potichu, je psaní testovatelného kódu. Nejprve to vypadá jako kompromis, ale zjistíte, že testovatelný kód je nakonec také modulární, udržovatelný a čitelný. Pokud stále potřebujete pomoc přesvědčit lidi toto je pěkná jednoduchá prezentace o výhodách testování jednotek.

12
Tom Martin

Pokud vaše stávající kódová základna neumožňuje testování jednotek a je již ve výrobě, můžete vytvořit více problémů, než vyřešíte tím, že se pokusíte změnit svůj kód tak, aby byl testovatelný jednotkou.

Možná budete raději namísto toho usilovat o zlepšení testování integrace. Tam je spousta kódu, který je prostě jednodušší psát bez testu jednotky, a pokud QA může ověřit funkčnost na základě dokumentu požadavků, je hotovo. Odeslat.

Klasickým příkladem toho je v mé mysli SqlDataReader vložený do stránky ASPX propojené s GridView. Kód je vše v souboru ASPX. SQL je v uložené proceduře. Co děláte test jednotky? Pokud stránka dělá to, co má dělat, měli byste ji opravdu přepracovat do několika vrstev, abyste měli co automatizovat?

11
Eric Z Beard

Jednou z nejlepších věcí při testování jednotek je, že váš kód bude jednodušší testovat, jak to děláte. Preexistingový kód vytvořený bez testů je vždy výzvou, protože protože neměly být testovány na jednotkách, není vzácné mít ve vaší třídě vysokou úroveň propojení mezi třídami, obtížně konfigurovatelnými objekty - jako je e-mail. odesílání referencí služby - atd. Ale nenechte se tím srazit! Uvidíte, že váš celkový návrh kódu se zlepší, jakmile začnete psát testy jednotek, a čím více budete testovat, tím více si budete jisti, že na něm provedete ještě více změn, aniž byste se obávali rozbití aplikace nebo zavedení chyb .

Existuje několik důvodů, proč jednotku testovat, ale postupem času zjistíte, že čas, který na testování ušetříte, je jedním z nejlepších důvodů. V systému, který jsem právě dodal, jsem trval na provádění automatizovaného testování jednotek, a to navzdory tvrzením, že trávím mnohem více času testováním, než bych testoval systém ručně. Po dokončení všech testů na jednotce jsem spustil více než 400 testovacích případů za méně než 10 minut a pokaždé, když jsem musel udělat malou změnu kódu, trvalo mi to, než jsem si byl jistý, že kód stále funguje bez chyb, deset minut. Dokážete si představit čas, který by člověk strávil provozováním těchto 400+ testovacích případů ručně?

Pokud jde o automatizované testování - ať už je to testování jednotky nebo přejímání - každý si myslí, že je zbytečnou snahou kódovat to, co můžete udělat ručně, a někdy je to pravda - pokud plánujete provádět testy pouze jednou. Nejlepší část automatizovaného testování je, že je můžete spustit několikrát bez námahy, a po druhém nebo třetím běhu je čas a úsilí, které jste ztratili je již zaplaceno.

Jednou z posledních rad by bylo nejen vyzkoušet váš kód, ale začít nejprve testovat (více viz TDD a BDD )

10
Alexandre Brasil

Jednotkové testy jsou také zvláště užitečné, pokud jde o refaktoring nebo přepisování kusu kódu. Pokud máte dobré pokrytí jednotkovými testy, můžete s jistotou refactor. Bez jednotkových testů je často těžké zajistit, abyste nic neporušili.

8
killdash10

Pracuji jako technik údržby špatně zdokumentované, hrozné a velké kódové základny. Přál bych si, aby lidé, kteří tento kód napsali, napsali pro něj testy jednotek.
Pokaždé, když provedu změnu a aktualizuji výrobní kód, mám strach, že bych mohl zavést chybu, protože jsem nezohlednil nějakou podmínku.
Kdyby psali test, provádění změn v kódové základně by bylo jednodušší a rychlejší (současně by byla kódová základna v lepším stavu).

Myslím, že jednotkové testy se ukázaly jako velmi užitečné při psaní api nebo rámců, které musí trvat mnoho let a musí je používat/upravovat/vyvíjet lidé jiné než původní kodéry.

7
mic.sca

Stručně řečeno - ano. Stojí za každou unci úsilí ... do určité míry. Testy jsou na konci dne stále kódem, a podobně jako u běžného růstu kódu, bude třeba vaše testy nakonec refaktorizovat, aby byly udržitelné a udržitelné. Je tu tuna GOTCHAS! pokud jde o testování jednotek, ale člověk, oh, člověk, nic, a tím myslím, že NIC NENÍ zmocněn vývojář provádět změny sebevědoměji než bohatá sada jednotkových testů.

Momentálně pracuji na projektu .... je to poněkud TDD, a většina našich obchodních pravidel je zapouzdřena jako testy ... právě teď máme asi 500 testů jednotek. V minulé iteraci jsem musel přepracovat náš zdroj dat a to, jak naše desktopová aplikace rozhraní s tímto zdrojem dat. Trvalo mi pár dní, celou dobu jsem pořád běžel testy jednotek, abych viděl, co jsem zlomil a opravil. Udělat změnu; Sestavte a spusťte své testy; opravit, co jste zlomil. Omyjte, vypláchněte, opakujte podle potřeby. To, co by tradičně trvalo dny QA a zatížení lodí stresem, bylo místo toho krátký a příjemný zážitek.

Připravte se dopředu, trochu extra úsilí, a to se vyplatí až 10krát později, když musíte začít obcházet základní funkce/funkce.

Koupil jsem si tuto knihu - je to Bible znalostí xUnit Testování - pravděpodobně jedna z nejpoužívanějších knih na mé polici a denně ji konzultuji: text odkaz

7
cranley

Občas budu já nebo jeden z mých spolupracovníků strávit pár hodin dostat se na dno mírně temné chyby a jakmile je příčina chyby nalezena 90% času, kdy tento kód není testován jednotkou. Test jednotky neexistuje, protože dev řeže rohy, aby se šetřil čas, ale pak ztratí toto a další ladění.

Trvání malého množství času na napsání testu jednotky může ušetřit hodiny budoucího ladění.

7
Jon Cahill

Když jste řekli, „naše kódová základna neumožňuje snadné testování“ je první známkou vůně kódu. Zápis testů jednotek znamená, že obvykle píšete kód jinak, aby byl kód testovatelnější. To je podle mého názoru dobrá věc, protože to, co jsem za ta léta viděl v psaní kódu, pro který jsem musel psát testy, mě nutilo navrhnout lepší design.

6
Keith Elder

Nevím. Mnoho míst nedělá test jednotky, ale kvalita kódu je dobrá. Microsoft provádí test jednotky, ale Bill Gates dal při své prezentaci modrou obrazovku.

6
BigTiger

Unit Testing rozhodně stojí za námahu. Bohužel jste si vybrali obtížný (ale bohužel běžný) scénář, do kterého jej implementujete.

Nejlepší výhoda, kterou získáte při testování jednotky, je při používání od základu - na několika vybraných malých projektech jsem měl to štěstí, že jsem před implementací svých tříd mohl napsat testy jednotek (rozhraní bylo v tomto již dokončeno) bod). Při správných jednotkových testech najdete a opravujete chyby ve svých třídách, zatímco jsou stále v plenkách a nikde poblíž komplexního systému, do kterého se v budoucnu bezpochyby začlení.

Pokud je váš software pevně objektově orientovaný, měli byste být schopni přidat testování jednotek na úrovni třídy bez přílišného úsilí. Pokud nejste tak šťastní, měli byste se pokusit začlenit testování jednotek, kdekoli to půjde. Ujistěte se, že když přidáte novou funkčnost, nové kousky jsou dobře definovány pomocí jasných rozhraní a zjistíte, že testování jednotek vám usnadní život.

6
Matt

O tomto tématu jsem napsal velmi velký blogový příspěvek. Zjistil jsem, že samotné testování jednotek nestojí za práci a obvykle se zkracuje, když se lhůty přibližují.

Namísto mluvení o testování jednotky z hlediska ověření po testování bychom se měli podívat na skutečnou hodnotu nalezenou, když jste se rozhodli napsat specifikaci/test/nápad před implementací.

Tento jednoduchý nápad změnil způsob, jakým píšu software, a já bych se nevrátil zpět k „starému“ způsobu.

Jak test první vývoj změnil můj život

5
Toran Billups

Jedna věc, kterou nikdo zatím nezmínil, je získání závazku všech vývojářů skutečně provozovat a aktualizovat existující automatizovaný test. Automatické testy, ke kterým se vracíte a zjistíte, že jsou z důvodu nového vývoje zlomené, ztratí spoustu hodnoty a učiní automatické testování opravdu bolestivým. Většina z těchto testů nebude indikovat chyby, protože vývojář testoval kód ručně, takže čas strávený jejich aktualizací je jen ztráta.

Přesvědčování skeptiků, aby nezničili práci, kterou ostatní dělají na jednotkových testech, je mnohem důležitější pro získání hodnoty z testování a může být snazší.

Testy trávení hodin aktualizací, které se pokazily kvůli novým funkcím pokaždé, když aktualizujete z úložiště, nejsou produktivní ani zábavné.

3
Samuel Åslund

TDD jsem objevil před pár lety a od té doby jsem psal všechny své domácí projekty, které jej využívají. Odhadl jsem, že projektu TDD to trvá zhruba ve stejnou dobu, než když je to potřeba, abych to dokázal spojit, ale mám takovou důvěru v konečný produkt, že nedokážu pomoci pocitu úspěchu.

Také cítím, že to zlepšuje můj styl designu (mnohem více orientovaný na rozhraní v případě, že musím posmívat věci dohromady), a jak zelený příspěvek nahoře píše, pomáhá s „kódováním zácpy“: když nevíte, co psát dál, nebo máte před sebou skličující úkol, můžete psát malý.

Nakonec jsem zjistil, že zdaleka nejužitečnější aplikace TDD je v ladění, i když pouze proto, že jste již vyvinuli dotazovací rámec, pomocí kterého můžete prodat projekt do výroby chyby opakovatelným způsobem.

3
Kaz Dragon

Ano - Testování jednotek rozhodně stojí za námahu, ale měli byste vědět, že to není stříbrná střela. Testování jednotek je funkční a budete muset pracovat, aby byl test aktualizován a relevantní jako změny kódu, ale nabízená hodnota stojí za úsilí, které musíte vložit. Schopnost refactor beztrestnosti je obrovská výhoda, protože můžete vždy ověřit funkčnost spuštěním testů po změně kódu. Trik spočívá v tom, že nebudeme příliš zavěšeni přesně na jednotce práce, kterou testujete, nebo na tom, jak testujete lešení a kdy test jednotky je opravdu funkční test, atd. Lidé se budou o této věci hádat celé hodiny na konci a realita je taková, že jakékoli testování, které provedete jako svůj psací kód, je lepší než to nedělat. Druhá axiom je o kvalitě a nikoliv o kvantitě - viděl jsem kódové základny s 1000 testy, které jsou v podstatě bezvýznamné, protože zbytek ve skutečnosti netestuje nic užitečného nebo nic konkrétního, jako jsou obchodní pravidla atd. Konkrétní domény. Viděl jsem také kódové databáze s 30% pokrytím kódem, ale testy byly relevantní, smysluplné a opravdu úžasné, protože testovaly základní funkčnost kódu, pro který byly napsány, a vyjádřily, jak by se měl kód použít.

Jedním z mých nejoblíbenějších triků při zkoumání nových rámců nebo kódových základen je psaní jednotkových testů, aby se zjistilo, jak věci fungují. Je to skvělý způsob, jak se dozvědět více o něčem novém, místo čtení suchého dokumentu :)

3
Vinny Carpenter

Nedávno jsem prošel přesně stejnou zkušeností na mém pracovišti a zjistil jsem, že většina z nich zná teoretické výhody, ale musela jsem je prodat, abych jim poskytla výhody, takže zde byly body, které jsem použil (úspěšně):

  • Šetří čas při provádění negativního testování, kde zpracováváte neočekávané vstupy (nulové ukazatele, mimo meze hodnot atd.), Protože vše můžete provádět v jediném procesu.
  • Poskytují okamžitou zpětnou vazbu v době kompilace týkající se úrovně změn.
  • Jsou užitečné pro testování reprezentací interních dat, které nemusí být během normálního běhu vystaveny.

a ten velký ...

  • Možná nebudete potřebovat testování jednotek, ale když přijde někdo jiný a upraví kód bez úplného porozumění, může zachytit spoustu hloupých chyb, které mohou udělat.
3
dlanod

Podle mých zkušeností jsou testy jednotek a testy integrace „MUSÍ BÝT“ ve složitých softwarových prostředích.

Chcete-li přesvědčit vývojáře ve vašem týmu, aby psali testy jednotek, možná budete chtít zvážit integraci analýzy regrese jednotek ve vašem vývojovém prostředí (například v denním procesu sestavování).

Jakmile vývojáři vědí, že pokud selže test jednotky, nemusejí trávit tolik času na ladění, aby našli problém, budou více povzbuzováni, aby je napsali.

Zde je nástroj, který poskytuje tyto funkce:

nástroj pro analýzu regresní jednotky

2
Liorp

Pokud používáte NUnit, je jednoduché, ale efektivní demo, spustit před nimi vlastní testovací sady NUnit. Vidět skutečnou testovací sadu, která trénuje s kódovou základnou, stojí za tisíc slov ...

2
Garth Gilmour

Jedinou věcí, kterou byste měli mít na paměti při testování jednotek, je to, že je to pohodlí pro vývojáře.

Naproti tomu funkční testy jsou pro uživatele: kdykoli přidáte funkční test, testujete něco, co uživatel uvidí. Když přidáte test jednotky, život vývojáře vám jen usnadní život. V tomto ohledu je to trochu luxus.

Tuto dichotomii mějte na paměti, když si musíte vybrat mezi napsáním jednotky nebo funkčním testem.

2
Cedric Beust

Souhlasím s názorem opačným oproti většině zde: Je to v pořádku, když nepíšete testy jednotek Obzvláště prototypově náročné programování (například AI) je obtížné kombinovat s testováním jednotek.

2
DSblizzard

Testování jednotek pomáhá hodně v projektech, které jsou větší, než jakýkoli jiný vývojář dokáže držet v hlavě. Umožňují vám spustit testovací sadu jednotek před kontrolou a zjistit, zda jste něco porušili. Tím se omezí lot v případech, kdy se musí posadit a otáčet palce, zatímco čeká, až někdo jiný opraví chybu, kterou zkontrolovali, nebo se dostane do potíží s vrácením své změny, takže můžete získat nějakou práci Hotovo. Je to také nesmírně cenné při refaktoringu, takže si můžete být jisti, že refactored kód projde všemi testy, které provedl původní kód.

2
Max Rible Kaehn

Pomocí sady testů jednotek můžete provádět změny kódu a ponechat zbývající funkce neporušené. Je to velká výhoda. Používáte sutie Unit test a regresní testovací sadu, když dokončíte kódování nové funkce.

2
Shinwari

Celkovým bodem testování jednotky je usnadnit testování. Je to automatické. "udělat test" a máte hotovo. Pokud je jeden z problémů, kterým čelíte, obtížně testovat kód, je to nejlepší důvod, proč používat testování jednotek.

1
Deathbob

Právě dnes jsem musel změnit třídu, pro kterou byl dříve napsán test jednotky.
Samotný test byl dobře napsán a zahrnoval scénáře testu, o kterých jsem ani neuvažoval.
Naštěstí všechny testy prošly a moje změna byla rychle ověřena a vložena do testovacího prostředí s důvěrou.

1
crowne

Při ručním testování softwaru máte obvykle malou sadu testů/akcí, které používáte. Nakonec automaticky změníte vstupní data nebo akce, abyste se mohli orientovat v známých problémech. Měly by tam být testy jednotek, aby vám připomněly, že věci nefungují správně.

Doporučuji psát testy před kódem, přidávat nové testy/data pro rozvoj funkčnosti hlavního kódu!

1
Ray Hayes

Jako student fyziky jsem skutečně velmi přesvědčen, že dokázat, že můj kód funguje tak, jak má. Dalo by se to logicky prokázat, což drasticky zvyšuje obtížnost, protože implementace se stává složitější, nebo můžete pomocí dobrého testování učinit (co nejblíže) empirický důkaz funkce.

Pokud neposkytnete logický důkaz funkce, musíte testovat. Jedinou alternativou je říct „Myslím, že kód funguje ....“

1
Fredrik

@George Stocker "Bohužel naše kódová základna neumožňuje snadné testování.". Každý souhlasí s tím, že testování jednotky přináší výhody, ale zdá se, že náklady na tuto kódovou základnu jsou vysoké. Pokud jsou náklady vyšší než přínosy, proč by o tom měli být nadšení? Poslouchejte své spolupracovníky; možná pro ně je vnímaná bolest jednotkových testů větší než vnímaná hodnota jednotkových testů.

Konkrétně se pokuste získat hodnotu co nejdříve, a ne nějaký dobrý pocit „xUnit je zelený“, ale čistý kód, který uživatelé a správci cení. Možná budete muset pověřit jednotkové testy pro jednu iteraci a pak projednat, zda to stojí za námahu nebo ne.

1
Trystan Spangler

Udělejte první testované věci, které se netýkají testování jednotek. Pracuji většinou v Perlu, takže toto jsou příklady specifické pro Perl, ale můžete se přizpůsobit.

  • Načítá se každý modul a kompiluje se správně? V Perlu se jedná o vytvoření Foo.t pro každou Foo.pm v kódové základně, která:

    use_ok( 'Foo' );
    
  • Jsou všechny POD (Plain Ol 'Documentation) formátovány správně? Použijte Test :: Pod k ověření platnosti formátování všech POD ve všech souborech.

Možná si nemyslíte, že se jedná o velké věci, a nejsou, ale mohu vám zaručit, že chytíte nějaký úbočí. Když tyto testy proběhnou jednou za hodinu, a to zachytí něčí předčasný závazek, budete mít lidi říkat "Hej, to je docela v pohodě."

1
Andy Lester

Jednou z výhod testování jednotek je předvídatelnost.

Před testováním jednotky jsem mohl předvídat s velkou přesností, jak dlouho bude kódování něco trvat, ale ne kolik času budu potřebovat pro ladění.

V těchto dnech, protože mohu naplánovat, jaké testy budu psát, vím, jak dlouho bude kódování trvat a na konci kódování je systém již debugován! To přináší předvídatelnost procesu vývoje, který odstraňuje hodně tlaku, ale stále si zachovává veškerou radost !!.

1
Raz

Unit Testing je jednou z nejvíce používaných metodik pro vysoce kvalitní kód. Jeho přínos ke stabilnějšímu, nezávislejšímu a zdokumentovanému kódu je dobře prokázán. Testovací kód jednotky je považován za nedílnou součást vašeho úložiště a jako takový vyžaduje vývoj a údržbu. Vývojáři se však často setkávají se situací, kdy zdroje investované do jednotkových testů nejsou tak plodné, jak by se dalo očekávat. V ideálním světě bude mít každá metoda, kterou kódujeme, řadu testů pokrývajících její kód a ověřující jeho správnost. Obvykle však kvůli časovým omezením některé testy vynecháme nebo napíšeme nekvalitní. V takové realitě, s přihlédnutím k množství zdrojů investovaných do vývoje a údržby jednotek, je třeba si položit otázku, který kód si zaslouží testování, s ohledem na čas, který je k dispozici? A z existujících testů, které testy se vlastně vyplatí udržovat a udržovat? Viz zde

0
RoiG

Testování jednotek vám pomůže uvolnit software s menším počtem chyb a zároveň snížit celkové náklady na vývoj. Kliknutím na odkaz se dozvíte více o výhodách testování jednotek

0
Steve_0

Kdo se snažíte přesvědčit? Inženýři nebo vedoucí? Pokud se snažíte přesvědčit své techniky spolupracovníky, myslím, že vaše nejlepší sázka je odvolat se na jejich touhu vytvořit vysoce kvalitní kus softwaru. Existuje mnoho studií, které ukazují, že najde chyby, a pokud jim záleží na dobré práci, mělo by to pro ně stačit.

Pokud se snažíte přesvědčit management, budete pravděpodobně muset udělat nějaké zdůvodnění nákladů/přínosů s tím, že náklady na vady, které nebudou odhaleny, jsou vyšší než náklady na psaní testů. Nezapomeňte také zahrnout nepředstavitelné náklady, například ztrátu důvěry zákazníků atd.

0
Craig H

To je velmi. Net-centrické, ale někdo se pokusil Pex?

Byl jsem velmi skeptický, dokud jsem to nezkusil - a páni, jaký výkon. Než jsem si pomyslel: „Tímto konceptem nebudu přesvědčen, dokud nepochopím, co to vlastně dělá ve prospěch mě“. Trvalo mi jediný běh, než jsem změnil názor a řekl: „Nezajímám , péče , jak víte, že existuje riziko fatální výjimky, ale tam je a teď vím, že se s tím musím vypořádat “

Možná jedinou nevýhodou tohoto chování je to, že nahlásí vše a dá vám šestiměsíční nevyřízené položky. Ale pokud jste měli kódový dluh, vždy jste měli kódový dluh, prostě jste to nevěděli. Řeknutí PM existuje potenciální dvě stě tisíc bodů selhání, když předtím, než jste si byli vědomi několika desítek, je nepříjemná vyhlídka, což znamená, že je nezbytné, aby byl tento koncept ) vysvětleno první.

0
Tom W