Co je testování jednotka?

hlasů
193

Viděl jsem mnoho otázek ptát ‚jak‘ jednotky test v určitém jazyce, ale není pochyb ptát ‚co‘, ‚proč‘ a ‚kdy‘.

  • Co je to?
  • Co to udělat pro mě?
  • Proč bych to měl používat?
  • Kdy bych měl použít (i když ne)?
  • Jaké jsou některé společné úskalí a mylné
Položena 04/08/2008 v 17:27
zdroj uživatelem
V jiných jazycích...                            


20 odpovědí

hlasů
182

Unit testování je, zhruba řečeno, testování kousky kódu v izolaci s testovacím kódem. Bezprostřední výhody, které přicházejí na mysl, jsou:

  • Spuštění testů se stává automatizovat-schopný a opakovatelné
  • Si můžete vyzkoušet na mnohem podrobnější úrovni než point-and-click testování pomocí GUI

Všimněte si, že pokud vaše testovací kód zapíše do souboru, otevře připojení k databázi, nebo dělá něco přes síť, je to vhodnější kvalifikovat jako integrační test. Testy integrace jsou dobrá věc, ale neměla by být zaměňována s unit testů. Jednotka Zkušební předpis by měly být krátké, sladké a rychle realizovat.

Další způsob, jak se dívat na jednotce testování je, že píšete testy jako první. Toto je známé jako Test-Driven Development (TDD v krátkosti). TDD přináší další výhody:

  • Nenapíšete spekulativní „bych mohl potřebovat v budoucnu“ kódu - jen tolik, aby se testy projít
  • Tento kód jste napsali je vždy pokryta zkouškami
  • Napsáním testu první, jste nuceni přemýšlet o tom, chcete-li volat kód, který obvykle zlepšuje vzhled kódu v dlouhodobém horizontu.

Pokud si nejste dělat jednotkové testování teď, doporučuji vám začít pracovat na tom. Získat dobrou knihu, prakticky jakýkoliv xUnit-kniha bude dělat, protože pojmy jsou velmi přenosné mezi nimi.

Někdy psaní unit testy mohou být bolestivé. Když se dostane takhle, se snaží najít někoho, kdo by vám pomohl, a odolat pokušení „stačí napsat tu zatracenou kód“. Unit testování je hodně jako mytí nádobí. Není to vždycky příjemné, ale zachovává svůj metaforický kuchyně čistá, a opravdu chcete, aby to bylo čisté. :)


Edit: Jeden mylná přichází na mysl, i když si nejsem jistý, jestli je to tak běžné. Slyšel jsem, projektový manažer řekl, že unit testy dělal tým psát celý kód dvakrát. Když to vypadá a cítí to tak dobře, děláte to špatně. Nejenže psát testy obvykle zrychlit vývoj, ale také vám dává pohodlný „teď jsem udělal“ indikátorem toho, že byste nemuseli jinak.

Odpovězeno 04/08/2008 v 17:36
zdroj uživatelem

hlasů
65

Nemyslím si nesouhlasit s Danem (i když lepší volbou může být jen neodpovědět) ... ale ...

Unit testování je proces psaní kódu otestovat chování a funkčnost systému.

Je zřejmé testuje zlepšit kvalitu kódu, ale to je jen povrchní přínos testování jednotek. Skutečné přínosy jsou:

  1. Ať je to jednodušší změnit technické provedení, ale zároveň zajistit nechcete změnit chování (refactoring). Správně jednotka testována kód může být agresivně refactored / vyčistit s malou šancí na lámání cokoliv, aniž by si toho všiml.
  2. Dát vývojáři jistotu při přidávání chování nebo dělat opravy.
  3. Dokumentovat svůj kód
  4. Indikují oblasti vašeho kódu, které jsou pevně spojené. Je těžké jednotka testovacího kódu, který je pevně spojený
  5. Poskytují prostředky pro použití vašeho API a hledat obtíže brzy
  6. Označuje metody a třídy, které nejsou velmi soudržná

Měli byste test jednotky, protože její ve vlastním zájmu dodat udržovatelný a kvalitní výrobek pro svého klienta.

Doporučil bych jej použít pro jakýkoliv systém nebo část systému, který modeluje real-world chování. Jinými slovy, je to velmi dobře hodí pro rozvoj podnikání. Já bych ji použít pro Jednorázové / obslužné programy. Já bych ji nelze použít pro části systému, které jsou problematické testu (UI je obyčejný příklad, ale to není vždy případ)

Největším úskalím je, že vývojáři testovat příliš velkou jednotku, nebo považují metodu celek. To platí zejména, pokud nechcete pochopit Inverze Control - v takovém případě se vaše jednotka testy se vždy obrátit na testování integrace end-to-end. Zkušební přístroj by měl testovat jednotlivé chování - a většina metody mají mnoho chování.

Největší mylná představa, že programátoři by neměli zkoušet. Jen špatné nebo líní programátoři věřit. V případě, že člověk stavět střechu to vyzkoušet? V případě, že lékař výměně srdeční chlopně netestovali nový ventil? Jen programátor může otestovat, zda jeho kód dělá to, co má v úmyslu udělat (QA můžete vyzkoušet případy hran - jak kód se chová, když je to dělat věci programátor nezamýšlí řekl, a klient může udělat přejímací zkoušky - má kód dělat co, co klient zaplatil za to dělat)

Odpovězeno 04/08/2008 v 17:41
zdroj uživatelem

hlasů
40

Hlavní rozdíl mezi jednotkové testy, na rozdíl od „jen otevření nového projektu a otestovat tento specifický kód“ je, že je automatizován , čímž opakovatelné .

Máte-li otestovat svůj kód ručně, může se přesvědčit, že je tento kód funguje dokonale - v jeho současném stavu . Ale co o týden později, když jste udělal drobnou modifikaci v něm? Jste ochotni ji opět znovu otestovat ručně vždy, když se něco změní v kódu? S největší pravděpodobností ne :-(

Ale pokud můžete spouštět testy kdykoliv, pomocí jediného kliknutí, stejným způsobem, během několika sekund , pak se okamžitě ukáže, kdykoliv je něco rozbité. A pokud jste také integrovat jednotkové testy do automatizovaného procesu sestavení, budou vás upozorní na chyby, a to iv případech, kdy se zdánlivě zcela nesouvisející změnu zlomil něco ve vzdálené části codebase - když by to ani nenapadlo, že existuje potřeba znovu otestovat konkrétní funkce.

To je hlavní výhoda unit testů přes testování ruky. Ale počkejte, je více:

  • unit testy zkrátit vývoj zpětnovazební smyčku dramaticky: s oddělenou zkušebnou může trvat týdny, abyste věděli, že je chyba v kódu, do té doby jste už zapomněli hodně z kontextu, tak to může trvat hodiny najít a opravit chybu; OTOH s unit testů, zpětná vazba cyklus se měří v sekundách a oprav chyb proces je obvykle v duchu jako „No sh * t, zapomněl jsem pro kontrolu této podmínky zde“ :-)
  • unit testy efektivně dokumentovat (vaše chápání) chování vašeho kódu
  • testovací přístroj vás nutí přehodnotit své individuální možnosti, což má za následek jednodušší, čistší designu

Unit testování rámce, podle pořadí, aby to pro vás snadné psát a spouštět testy.

Odpovězeno 14/03/2010 v 18:20
zdroj uživatelem

hlasů
29

Nikdy jsem nebyl učil jednotkové testování na univerzitě, a to mi chvíli trvalo, než se „dostat“ to. Četl jsem o tom, šel „Ach, jo, automatizované testování, které by mohly být v pohodě, myslím“, a pak jsem na to zapomněl.

Je to trochu trvalo déle, než jsem opravdu přišel na bod: Řekněme, že pracujete na velkém systému, a píšete malý modul. Shrnuje, co si jen dát prostřednictvím svých kroků, funguje to skvěle, můžete přejít k dalšímu úkolu. Devět měsíců v řadě a dvě verze později někdo provede změnu nějakého zdánlivě nesouvisejícím v rámci programu, a to zlomí modul. Horší je, že testovat své změny a jejich kód funguje, ale nemají otestovat modul; peklo, ale dokonce ani nemusí vědět váš modul existuje .

A teď máte problém: člení kód je v kufru a nikdo ani neví. Nejlepší věc je vnitřní testovací najde to před vámi lodi, ale upevnění kód, který pozdě ve hře je drahé. A pokud to není vnitřní Tester najde ... no, to může dostat opravdu velmi nákladné.

Řešení je jednotkové testy. Budou chytat problémy při psaní kódu - což je v pořádku - ale mohl jste udělal, že ručně. Skutečný přínos je, že chytí problémů devět měsíců v řadě, když jste nyní pracuje na zcela jiném projektu, ale v létě stážista si myslí, že to bude vypadat chudší, pokud tyto parametry jsou v abecedním pořadí - a pak test jednotka jste napsal cestu zpět selže, a někdo hází věci na stážista, dokud se změní pořadí parametru zpět. To je „proč“ unit testů. :-)

Odpovězeno 19/09/2008 v 13:45
zdroj uživatelem

hlasů
12

Štěpkování v na filozofických klady jednotkové testování a TDD zde jsou některé z klíčových oni „žárovka“ pozorování, která mi připadala na mých předběžných prvních kroků na cestě k osvícení TDD (žádný originál nebo nutně novinky) ...

  1. TDD NEZNAMENÁ dvakrát psaní množství kódu. Zkušební předpis je obvykle poměrně rychlé a bezbolestné psát a je klíčovou součástí vašeho návrhového procesu a kriticky.

  2. TDD vám pomůže uvědomit si, kdy přestat kódování! Vaše testy vám jistotu, že jste udělali dost pro tuto chvíli a může zastavit ladění a přejít na další věc.

  3. Zkoušky a kód společně pracovat na dosažení lepšího kódu. Váš kód by mohl být špatný / buggy. Váš test by mohl být špatný / buggy. V TDD se opírá o šancích na oba jsou špatné / kočárek bytí poměrně nízká. Často jeho test, který potřebuje, kterým se ale, že je to stále dobrý výsledek.

  4. TDD pomáhá při kódování zácpa. Víte, že pocit, že máte tolik práce sotva vědět, kde začít? Je pátek odpoledne, pokud jste právě odkládat na několik dalších hodin ... TDD umožňuje zhmotnit velmi rychle, co si myslíte, že je třeba udělat, a dostane vaše kódování rychle pohybuje. Také, jako laboratorní krysy, myslím, že jsme všichni reagují na té velké zelené světlo a tvrději pracovat, aby ji znovu vidět!

  5. V podobném duchu, tyto typy návrhář můžete vidět, co oni pracovali. Mohou zatoulat na džus / cigarety / přestávky iPhone a vrátit se k monitoru, který jim okamžitě dává vizuální podnět, aby se tam, kde se dostal do. TDD nám dává něco podobného. To je lépe vidět, kam jsme se dostali, když je život zasáhne ...

  6. Myslím, že to byl Fowler, který řekl: „Nedokonalé testy, jezdí často, jsou mnohem lepší než perfektní testů, které se nikdy písemných vůbec“. I interpretovat to tak, že mi svolení psát testy, kde si myslím, že to bude nejužitečnější, i když zbytek mého pokrytí kódu je žalostně neúplná.

  7. TDD pomáhá při všech druzích překvapujících cestách na celé čáře. Dobré unit testy mohou pomoci dokumentu, co se něco dělat, mohou vám pomoci přenést kód z jednoho projektu do druhého a dát vám neodůvodněné pocit nadřazenosti nad svými non-zkoušení kolegy :)

Tato prezentace je vynikající úvod do všech chutné dobroty testování s sebou nese.

Odpovězeno 24/08/2008 v 22:58
zdroj uživatelem

hlasů
7

Chtěl bych doporučit xUnit testování vzory knihu Gerard Meszaros. Je to velký, ale je to skvělý zdroj na testování jednotek. Zde je odkaz na své webové stránky, kde se probírá základy testování jednotek. http://xunitpatterns.com/XUnitBasics.html

Odpovězeno 14/03/2010 v 19:10
zdroj uživatelem

hlasů
5

Používám unit testy, aby ušetřil čas.

Při budování obchodní logiku (nebo přístup k datům) funkcionalita testování může často zahrnovat psaní věci do velkých obrazovkách, které mohou nebo nemusí být ještě dokončena. Automatizaci těchto testů šetří čas.

Pro mě unit testy jsou jakousi modularised zkušebního svazku. Tam je obvykle alespoň jedna zkouška na veřejnou funkci. Píšu další testy, které pokrývají různé chování.

Všechny zvláštní případy, které jste si mysleli, ze při vývoji kódu mohou být zaznamenány v kódu v jednotkové testy. Jednotkové testy také stát zdrojem příkladů, jak používat kód.

Je to mnohem rychlejší, abych zjistil, že můj nový kód láme něco v mých unit testů pak zkontrolovat v kódu a mají některé front-end developer najít problém.

Pro testování datové Snažím se psát testy, které buď nemají žádnou změnu nebo uklidit po sobě.

Testy jednotek se nebude moci vyřešit všechny požadavky na testování. Budou moci ušetřit čas potřebný pro vývoj a zkušební základní části aplikace.

Odpovězeno 17/09/2008 v 01:38
zdroj uživatelem

hlasů
5

To je můj názor na něj. Řekl bych, že testovací jednotka je praxe psaní softwarových zkoušky, aby ověřil, zda v reálném software dělá to, co je chtěl. To začalo s JUnit na světě Java a stala se nejlepší praxe v PHP, stejně s SimpleTest a PHPUnit . Je to základní praxe Extreme programování a pomůže vám, abyste se ujistili, že váš software stále funguje jak má po úpravě. Pokud máte dostatečné pokrytí testy, můžete tak učinit hlavní refactoring, stanovení chyby nebo přidání funkcí rychle s mnohem menším strachem zavedení další problémy.

To je nejúčinnější, když jsou všechny jednotkové testy mohou být spuštěny automaticky.

Unit testování je obecně spojeno s rozvojem OO. Základní myšlenkou je vytvořit skript, který nastaví prostředí pro váš kód a pak vykonává ji; píšete tvrzení, určit zamýšlený výstup, který byste měli obdržet a pak spustit testovací skript pomocí rámce, jako je uvedeno výše.

Rámec poběží všechny testy proti kódu a následně podat zprávu o úspěchu či neúspěchu každého testu. PHPUnit je spustit z příkazového řádku Linuxu ve výchozím nastavení, i když existují rozhraní HTTP pro něj k dispozici. SimpleTest je webová přírodou a je mnohem snazší se dostat nahoru a běží, IMO. V kombinaci s Xdebug, PHPUnit vám může poskytnout automatizované statistiky pro pokrytí kódu, který někteří lidé najít velmi užitečné.

Některé týmy psát háčky ze svého Subversion, takže jednotkové testy jsou spuštěny automaticky při každém potvrdit změny.

Je dobrým zvykem, aby se vaše unit testy ve stejném úložišti jako aplikace.

Odpovězeno 05/08/2008 v 00:53
zdroj uživatelem

hlasů
4

Knihovny jako NUnit , xUnit nebo JUnit jsou jen povinné, pokud chcete rozvíjet své projekty pomocí TDD přístup popularizoval Kent Beck:

Můžete si přečíst úvod Test Driven Development (TDD) nebo kniha Kent Beck programování řízené testy: Podle příkladu .

Potom, pokud chcete být jisti, že vaše testy pokrytí „dobrý“ část kódu, můžete použít software jako NCover , JCover , PartCover nebo cokoliv jiného. Oni ti řeknu procento pokrytí kódu. V závislosti na tom, kolik jste zběhlí v TDD, budete vědět, jestli jste cvičil to dost dobře :)

Odpovězeno 14/03/2010 v 18:22
zdroj uživatelem

hlasů
3

Myslím si, že bod, který nechcete pochopit, že testovací jednotka rámce jako NUnit (a podobně) vám pomůže při automatizaci malých až středně velkých zkoušek. Obvykle můžete spustit testy v GUI (to je případ s NUnit , například) pouhým kliknutím na tlačítko a pak - snad - viz ukazatel průběhu svítit zeleně. Pokud se ukáže, červený, rámcem ty, které test selhal a co přesně se stala chyba zobrazuje. V normálním jednotky test, se často používá tvrzení, například Assert.AreEqual(expectedValue, actualValue, "some description")-, takže v případě, že dvě hodnoty nejsou shodné uvidíte chybu rčení „nějaký popis: Očekávaná hodnota <expectedValue> ale <actualValue>“.

Tak jako testovací závěr jednotka v takovém případě poskytne testování rychlejší a mnohem pohodlnější pro vývojáře. Můžete spustit všechny jednotkové testy před spácháním nový kód, takže neporušují proces sestavení dalších vývojářů na stejném projektu.

Odpovězeno 14/03/2010 v 18:25
zdroj uživatelem

hlasů
3

Unit testování je praxe, aby se ujistil, že funkce nebo modul, který budete realizovat se bude chovat, jak se očekávalo (požadavky), a také, aby se ujistil, jak se chová v situacích, jako jsou okrajové podmínky, a vstup je neplatný.

xUnit , NUnit , mbUnit , atd. jsou nástroje, které vám pomohou při psaní testů.

Odpovězeno 14/03/2010 v 18:22
zdroj uživatelem

hlasů
3

Unit testování je o psaní kódu, který testuje kód aplikace.

Unit část názvu je o záměru testování malých jednotek kódu (Jedním ze způsobů, například) najednou.

xUnit je tam na pomoc s tímto testováním - jsou rámce, které pomáhají s tímto. Část, která je automatizovaná testovací běžců, které vám sdělit, co testy nezdaří a ty, které procházejí.

Mají také zařízení na nastavení společného kodexu, které je třeba v každém testu před rukou a zničit to, když všechny testy hotové.

Můžete mít test zkontrolovat, že očekává, že výjimka byla vyvolána, aniž by bylo nutné napsat celý try catch blokovat sami.

Odpovězeno 14/03/2010 v 18:19
zdroj uživatelem

hlasů
3

Použít Testivus . Vše, co potřebujete vědět, je tady :)

Odpovězeno 17/09/2008 v 01:48
zdroj uživatelem

hlasů
2

Za prvé, ať už mluvíme o testování jednotky nebo jakékoliv jiné druhy automatizované testování (integrace, Load, testování UI atd.), Hlavní rozdíl od toho, co navrhuji, je, že je automatizovaný, opakovatelný a nevyžaduje žádné lidské zdroje ke konzumaci (= nikdo musí provést testy, které obvykle běží při stisknutí tlačítka).

Odpovězeno 14/03/2010 v 18:22
zdroj uživatelem

hlasů
2

Test Driven Development druh převzal test termín Unit. Jako starý časovač zmíním o obecnější definici.

Jednotka test také znamená, že testování jedné složky do většího systému. Tato jediná složka může být DLL, exe, knihovna tříd, atd. Mohlo by to být i jediný systém v aplikaci pro multi-systému. Takže nakonec Unit test skončí být testování, co chcete volat jediný kus většího systému.

Ty by pak se přesunout do integrovaného nebo testování systému testováním, jak všechny komponenty spolupracují.

Odpovězeno 24/08/2008 v 23:34
zdroj uživatelem

hlasů
2

Unit testování je testování jednotky kódu (např jediná funkce) aniž by bylo zapotřebí infrastruktury, která tato jednotka kódu se opírá o. tj otestovat izolovaně.

Pokud se například, funkce, kterou testujete se připojuje k databázi a dělá aktualizaci, v testu jednotky možná nebudete chtít dělat tuto aktualizaci. Ty by kdyby byl integrační testy, ale v tomto případě tomu tak není.

Takže testovací jednotka bude vykonávat funkci uzavřený v „funkci“, kterou testujete, bez vedlejších účinků aktualizaci databáze.

Řekněme, že vaše funkce vyvolány některá čísla z databáze a pak provádí standardní výpočet odchylky. Co se snažíte, aby zde vyzkoušet? Že standardní odchylka je vypočítána správně, nebo že data vrácena z databáze?

Při testu jednotky si jen chcete vyzkoušet, že standardní odchylka je vypočtena správně. V integračním testu chcete otestovat standardní výpočet odchylky a načítání databáze.

Odpovězeno 15/08/2008 v 18:42
zdroj uživatelem

hlasů
1

To odpoví, proč byste měli dělat jednotkové testování.


Tyto 3 videa níže testování krycí jednotky v JavaScriptu, ale obecné principy platí ve většině jazyků.

Unit testování: Minuty Teď ušetří hodiny později - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (velmi dobré) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Psaní Testovatelné JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Teď jsem jen učení o toto téma, tak jsem nemusí být 100% správné a je tu víc, než to, co jsem popisoval tady, ale moje základní znalost jednotky testování je, že budete psát nějaký test kód (která je oddělena od svého hlavním code), který volá funkci v hlavním kódu se vstupními (argumenty), že funkce vyžaduje a kód zkontroluje, pokud se dostane zpět platnou návratovou hodnotu. Pokud tomu tak vrátit platnou hodnotu testovacího rámce jednotky, kterou používáte ke spuštění testů ukazuje zelenou (vše dobře) v případě, že hodnota je neplatná dostanete červené světlo a pak můžete vyřešit problém hned před vámi uvolnit nový kód k výrobě, bez testování můžete skutečně nemohl chytit chybu.

Takže psát testy pro vás aktuální kód a vytvořit kód tak, že projde testem. O několik měsíců později vy nebo někdo jiný třeba měnit funkce v hlavním kódu, protože dříve se již písemný test kód pro tuto funkci nyní spustit znovu a test může selhat, protože kodér zavedena logická chyba ve funkci nebo něco vrátit úplně odlišný od toho, co která funkce se má vrátit. Opět bez zkoušky v místě, které chyba může být těžké vypátrat, jak to může možná mít vliv na jiný kód, jak dobře a bude bez povšimnutí.


Také skutečnost, že budete mít počítačový program, který běží přes váš kód a testuje ho místo jej ručně dělá na stránce prohlížeče straně šetří čas (jednotka testování JavaScript). Řekněme, že změníte funkci, která se používá nějaký skript na webové stránce, a funguje to všechno dobře a dobré pro svůj nový účel. Ale pojďme se také říci, argumenty důvodu, že tam je další funkce máte někde jinde v kódu, který závisí na tom nově upraveného funkcí pro to, aby správně fungovat. To závisí funkce může nyní přestat fungovat kvůli změnám, které jste provedli na první funkci, avšak bez testů v místě, které jsou spuštěny automaticky v počítači nebudete Všimněte si, že je tu problém s touto funkcí, dokud se skutečně proveden a budete muset ručně přejít na webovou stránku, která obsahuje skript, který vykonává závislou funkci, teprve pak zjistíte, že tam je chyba, protože změny, které jste provedli na první funkci.

Zopakovat, s testy, které jsou spuštěny při vývoji vaší žádosti bude chytit tyto druhy problémů, jak jste kódování. Nemít testy na místě byste museli ručně projít celou aplikaci a dokonce pak to může být obtížné rozpoznat chybu, naivně ji vyslat do výroby a po chvíli vám uživatel druh odešle zprávu o chybě (která nebude tak dobrý jako vaše chybových zpráv v rámci zkoušení).


Je to docela matoucí, když jste poprvé uslyší toto téma a vy myslíte na sebe, nejsem již testuje svůj kód? A kód, který jste napsali pracuje jako to má již, „proč já potřebovat další rámec?“ ... Ano, už jste testování kódu, ale počítač je lepší dělat. Musíte jen napsat dost dobré testy na funkci / jednotky kódu jednou a zbytek je postaráno pro vás mocného procesoru namísto byste museli ručně zkontrolovat, že všechny vaše kódu se stále pracuje, když uděláte změnu váš kód.

Také nemáte na jednotku otestovat svůj kód, pokud nechcete, ale to se vyplatí jako projekt / kódové základny začne zvětšují jako šance na zavedení bugs zvyšuje.

Odpovězeno 18/07/2015 v 18:34
zdroj uživatelem

hlasů
1

Co dělat, když jste dostali hromadu keců a zdá se, jako byste se zasekl v trvalém stavu vyčištění, že víte, s přidáním jakékoliv nové funkce nebo kód může přerušit aktuální sadu, protože aktuální software je jako domeček z karty?

Jak můžeme udělat Unit testování pak?

Začnete malé. Projekt právě jsem se dostal do neměl jednotkové testování před několika měsíci. Když pokrytí bylo, že nízká, budeme jen vybrat soubor, který měl žádnou pokrytí a klikněte na „přidat testy“.

Právě teď jsme se na více než 40%, a podařilo se nám odstřelovat většinu nízko visící ovoce.

(Nejlepší na tom je, že i při této nízké úrovni krytí, které jsme již narazit na mnoha příkladech z kódu dělá špatnou věc, a testování ho chytil. To je obrovský stimul tlačit lidi k přidat další testování.)

Odpovězeno 22/08/2008 v 19:19
zdroj uživatelem

hlasů
1

Šel jsem na prezentaci na jednotce testování na FoxForward 2007 a nikdy bylo mi řečeno, jednotka test něco, který pracuje s daty. Koneckonců, pokud si vyzkoušet na skutečná data, výsledky jsou nepředvídatelné, a pokud nechcete testovat na živých dat, nejste ve skutečnosti testování kódu jste napsal. Bohužel, to je většina z kódování dělám v těchto dnech. :-)

Já jsem mít šanci na TDD v poslední době, když jsem psal rutinní zachránit a obnovit nastavení. Za prvé, ověřil jsem si, že bych mohl vytvořit objekt úložiště. Potom, že má k dispozici metodu jsem potřeboval zavolat. Tedy, že bych mohl nazvat. Pak, že bych mohl projít to parametry. Pak, že bych mohl předat specifické parametry. A tak dále, až se mi konečně ověření, že by uložení zadaného nastavení, dovolte mi, abych to změnit, a poté jej obnovit, pro několik různých syntaxí.

Nedostal jsem se až do konce, protože jsem potřeboval-the-běžné-teď Zatraceně, ale bylo to dobré cvičení.

Odpovězeno 22/08/2008 v 19:10
zdroj uživatelem

hlasů
0

Unit testování a TDD obecně umožňuje mít kratší zpětné cykly o software, který píšete. Místo toho, aby velké testovací fázi na samém konci provádění, budete postupně vyzkoušet vše, co napíšete. To zvyšuje kvalitu kódu moc, jak si okamžitě vidět, kde byste mohli mít chyby.

Odpovězeno 03/05/2017 v 09:33
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more