it-swarm-eu.dev

Proč TDD funguje?

Testem řízený vývoj (TDD) je v těchto dnech velký. Často to považuji za doporučené řešení pro celou řadu problémů zde v Programmerech SE a dalších místech. Zajímalo by mě, proč to funguje.

Z technického hlediska mě hádá ze dvou důvodů:

  1. Přístup "write test + refactor till pass" vypadá neuvěřitelně anti-inženýrství. Pokud by například stavební inženýři použili tento přístup pro stavbu mostů nebo pro návrháře automobilů pro svá auta, upravili by své mosty nebo automobily za velmi vysoké náklady a výsledkem by byla opravená nepořádek bez dobře promyšlené architektury . Směrnice „refaktor do průchodu“ je často považována za pověření zapomenout na architektonický návrh a udělat vše, co je nezbytné , aby vyhověl testu; jinými slovy, test spíše než uživatel stanoví požadavek. Jak můžeme v této situaci zaručit dobré „ility“ ve výsledcích, tj. Konečný výsledek, který je nejen správný, ale také roztažitelný, robustní, snadno použitelný, spolehlivý, bezpečný, bezpečný atd.? To je to, co obvykle architektura dělá.
  2. Testování nemůže zaručit fungování systému; to může jen ukázat, že tomu tak není. Jinými slovy, testování vám může ukázat, že systém obsahuje vady, pokud selže test, ale systém, který projde všemi testy, není bezpečnější než systém, který je selhal. Pokrytí testu, kvalita testu a další faktory jsou zde zásadní. Falešné bezpečné pocity, které „všechny zelené“ výsledky způsobují mnoha lidem, byly v civilním a leteckém průmyslu hlášeny jako extrémně nebezpečné, protože to lze interpretovat jako „systém je v pořádku“, když to ve skutečnosti znamená „systém je stejně dobrý“ jako naše strategie testování ". Strategie testování se často nekontroluje. Nebo kdo testuje testy?

Stručně řečeno, jsem více znepokojen bitem "řízeným" v TDD než bitem "testovacím". Testování je naprosto v pořádku; to, co nechápu, je řídit design tím, že to dělá.

Chtěl bych vidět odpovědi obsahující důvody, proč je TDD v softwarovém inženýrství dobrou praxí a proč problémy, které jsem vysvětlil výše, nejsou relevantní (nebo dostatečně relevantní) v případě softwaru. Děkuju.

93
CesarGon

Myslím, že je tu jedna mylná představa. V softwarovém designu je design velmi blízký produktu. Ve stavebnictví, architektuře je design oddělen od skutečného produktu: existují plány, které drží design, které se poté zhmotňují do hotového výrobku, a ty jsou odděleny velkým množstvím času a úsilí.

TDD testuje návrh. Vyzkouší se však také každý návrh vozu a návrh budovy. Stavební techniky jsou nejprve spočítány, poté testovány v menším měřítku a poté testovány ve větším měřítku, než jsou umístěny do skutečné budovy. Když například vynalezli H-paprsky a zatížení, buďte si jisti, že to bylo vyzkoušeno a vyzkoušeno ještě předtím, než s ním skutečně postavili první můstek.

Návrhy automobilů se také testují navrhováním prototypů a ano, určitě úpravou věcí, které nejsou zcela správné, dokud nesplní očekávání. Část tohoto procesu je však pomalejší, protože, jak jste řekli, s výrobkem se nemůžete moc pohrávat. Ale každý redesign automobilu vychází ze zkušeností získaných od dřívějších a každá budova má za sebou asi tisíce let základů o významu prostoru, světla, izolace, síly atd. Podrobnosti se mění a zlepšují, a to jak v budovách a v přepracování pro novější.

Také jsou testovány součásti. Možná ne přesně ve stejném stylu jako software, ale mechanické části (kola, zapalovače, kabely) se obvykle měří a vystavují stresu, aby se zjistilo, že velikosti jsou správné, žádné abnormality není vidět, atd. Mohou být rentgenovány nebo laserově měří, poklepávají na cihly, aby zjistili rozbité cihly, mohli být skutečně testováni v nějaké konfiguraci nebo v jiné, nebo nakreslili omezenou reprezentaci velké skupiny, aby ji opravdu otestovali.

To jsou všechny věci, které můžete zavést pomocí TDD.

Testování samozřejmě není zárukou. Programy havarují, auta se pokazí a budovy začnou dělat legrační věci, když vítr fouká. Ale ... 'bezpečnost' není boolovská otázka. I když nemůžete nikdy zahrnout všechno, být schopen pokrýt - řekněme - 99% možností je lepší než pokrýt pouze 50%. Nezkoušení a pak zjištění, že ocel se neusadila dobře, je křehká a při prvním úderu kladiva se zlomí, když právě vložíte svou hlavní strukturu, je obyčejná ztráta peněz. Že existují i ​​další obavy, které by mohly budovu ještě ublížit, neznamená to, že by byla o nic méně hloupá, aby vám umožnil snadno předešlou vadu, která váš návrh zredukuje.

Co se týče praxe TDD, jedná se o vyvážení. Náklady na provedení jedné cesty (například neprovádění zkoušek a následné vyzvednutí kusů) versus náklady na provedení jiné cesty. Je to vždy rovnováha. Nemyslete si však, že jiné konstrukční procesy nemají testování a TDD zavedeny.

66
Inca

IMO, většina úspěšných příběhů pro TDD je falešná a pouze pro marketingové účely. Může to být velmi málo úspěchů, ale pouze pro malé aplikace. Pracuji na velké aplikaci Silverlight, kde se používají principy TDD. Aplikace má stovky testů, ale stále není stabilní. Několik částí aplikace nelze testovat kvůli složitým interakcím s uživatelem. Výsledné testy se spoustou falešných a těžko pochopitelných kódů.

Zpočátku, když jsme vyzkoušeli TDD, všechno se zdá dobré. Dokázal jsem napsat spoustu testů a vysmívat se částem, které jsou těžké pro jednotkový test. Jakmile budete mít spravedlivé množství kódu a je vyžadována změna rozhraní, vaše je zašroubováno. Je třeba opravit mnoho testů a přepíšete více testů, než je skutečná změna kódu.

Peter Norvig vysvětluje svůj pohled na TDD v knize Coders At Work.

Seibel: A co myšlenka použití testů k řízení designu?

Norvig: Testy považuji spíše za způsob opravy chyb než za způsob designu. Tento extrémní přístup říká: „No, první věc, kterou uděláte, je napsat test, který říká, že na konci dostanu správnou odpověď,“ a poté to spustíte a uvidíte, že selže, a pak řeknete: „Co mám dělat? potřebujete další? “- to se mi nezdá jako správný způsob, jak něco navrhnout. Vypadá to, že by to mělo smysl, jen kdyby to bylo tak jednoduché, že řešení bylo předem nařízeno. Myslím, že o tom musíte nejdřív přemýšlet. Musíte říct: „Jaké jsou kousky? Jak mohu psát testy na kousky, dokud nevím, co jsou některé? “ A jakmile to uděláte, pak je dobrou disciplínou mít testy pro každou z těchto skladeb a dobře porozumět tomu, jak spolu vzájemně spolupracují, případy hranic a tak dále. Všichni by měli mít testy. Ale nemyslím si, že řídíte celý návrh tím, že říká: „Tento test selhal.“

26
Navaneeth K N

Test Driven Design pracuje pro mě z následujících důvodů:

Jedná se o spustitelnou formu specifikace.

To znamená, že můžete vidět z testovacích případů:

  1. [~ # ~], že [~ # ~] - kód, který se nazývá, vyplní specifikaci, protože očekávané výsledky jsou přímo v testovacích případech. Vizuální kontrola (která očekává, že testovací případy projdou) může okamžitě říci „ach, tento test zkontroluje, že volání fakturySpolečnost by měla mít za této situace výsledek“.
  2. [~ # ~] jak [~ # ~] by měl být kód vyvolán. Skutečné kroky potřebné k provedení testů jsou specifikovány přímo bez externího lešení (databáze jsou zesměšňovány atd.).

Nejprve napíšete pohled zvenku.

Často je kód psán tak, že nejprve vyřešíte problém, a pak přemýšlíte o tom, jak se má volat právě napsaný kód. To často dává nepříjemné rozhraní, protože je často jednodušší „jednoduše přidat příznak“ atd. Když si pomyslíme „musíme udělat TUTO, aby vypadaly testery jako TAT“ dopředu, když to otočíš. To poskytne lepší modularitu, protože kód bude psán podle volajícího rozhraní, nikoli naopak.

Výsledkem bude obvykle také čistší kód, který vyžaduje méně vysvětlující dokumentaci.

Uděláte rychleji

Vzhledem k tomu, že máte specifikaci pro spustitelný formulář, jste hotovi, když prochází celá sada testů. Můžete si přidat další testy, jak objasňujete věci na podrobnější úrovni, ale jako základní princip máte velmi jasný a viditelný ukazatel pokroku a po dokončení.

To znamená, že můžete zjistit, kdy je práce nezbytná nebo ne (pomůže to projít testem), že nakonec musíte udělat méně.

Pro ty, kteří o tom přemýšlejí, může být užitečné, doporučuji vám použít TDD pro vaši další knihovní rutinu. Pomalu nastavte spustitelnou specifikaci a nechte kód projít testy. Po dokončení je specifikace runnable dostupná pro každého, kdo potřebuje vědět, jak vyvolat knihovnu.

Nedávné studium

„Výsledky případových studií naznačují, že hustota defektů před uvolněním čtyř produktů se snížila mezi 40% a 90% ve srovnání s podobnými projekty, které nepoužívaly praxi TDD. Subjekty subjektivně zaznamenaly 15 až 35% nárůst v počáteční vývojový čas po přijetí TDD. “ ~ Výsledky a zkušenosti 4 průmyslových týmů

25
user1249

Proces vytváření softwaru není proces psaní kódu. Žádný softwarový projekt by neměl být spuštěn bez plánu „širokého rozsahu“. Stejně jako projekt přemostění dvou břehů řeky potřebuje takový plán jako první.

TDD přístup souvisí (většinou) s testováním jednotek - alespoň tak to lidé o tom přemýšlejí - to je vytváření nejnižších bitů softwarového kódu. Když již byly definovány všechny funkce a chování a my vlastně víme, čeho chceme dosáhnout.

Ve stavebnictví to vypadá trochu takto:

"Máme tyto dva kusy kovu spojeny dohromady a spojení musí udržovat střižné síly v řádu x." Vyzkoušejte, která metoda připojení je nejlepší pro to “

Pro testování, zda software funguje jako celek, navrhujeme další druhy testů, jako jsou testy použitelnosti, integrační testy a akceptační testy. Také by měly být definovány před zahájením samotné práce na psaní kódu a jsou prováděny poté, co jsou testy jednotky zelené.

Viz model V: http://en.wikipedia.org/wiki/V-Model_%28software_development%29

Uvidíme, jak by to fungovalo pro most:

  1. Místní vláda říká společnosti vyrábějící most: „Potřebujeme most, abychom spojili tyto dva body. Most musí být schopen umožnit n množství provozu za hodinu a být připraven na 21. prosince 2012“ - to je definice akceptační test. Společnost nedostane plnou částku (nebo žádné) peníze, pokud tento test nemůže projít.

  2. Vedení společnosti rozhoduje o harmonogramu projektu. Zřídili pracovní týmy a stanovili cíle pro každý tým. Pokud týmy tyto cíle nesplní - most nebude postaven včas. Je zde však určitá úroveň flexibility. Pokud má jeden z týmů nějaké problémy, může to společnost vyrovnat změnou požadavků, změnou subdodavatelů, najmutím dalších lidí atd. Tak, aby celý projekt stále splňoval cíl stanovený v bodě 1.

  3. V týmu odpovědném za návrh konkrétních komponent mostu to vypadá jako v příkladu, který jsem uvedl výše. Někdy je řešení zřejmé, protože máme velké množství znalostí o budování mostů (je to jako používat osvědčenou knihovnu při vývoji softwaru - prostě předpokládáte, že funguje tak, jak je inzerováno). Někdy musíte vytvořit několik návrhů a vyzkoušet je, abyste vybrali ten nejlepší. Stále jsou však předem známa kritéria, na nichž je komponenta testována.

19
Mchl

Podle mého názoru TDD funguje, protože

  • Vynutí vás, abyste definovali, co má jednotka dělat, než se rozhodnete pro implementaci na úrovni přesnosti, která není obecně pokryta žádným dokumentem o specifikacích nebo požadavcích.
  • Díky tomu je váš kód opětovně použitelný, protože jej musíte použít v testovacích i produkčních scénářích
  • Povzbuzuje vás k tomu, abyste psali kód v menším rozjímači, abyste vyzkoušeli kousky, které vedou k lepším návrhům

Konkrétně v bodech, které zvyšujete

  • Kód je poddajnější než cihla nebo ocel, takže je levnější jej upravit. Je stále levnější, pokud máte testy, které zajistí, že se chování nezmění
  • TDD není omluva, že nedělá design - architektura na vysoké úrovni se stále doporučuje, ale ne příliš podrobně. Big Up Front Design se nedoporučuje, ale doporučuje se dělat jen tolik designu
  • TDD nemůže zaručit, že systém funguje, ale zabraňuje proklouznutí mnoha malých chyb, které by jinak unikly. Také proto, že obecně podporuje lépe faktorovaný kód, je často snazší porozumět, takže je méně pravděpodobné, že bude buggy
18
Gavin Clarke

TL; DR

Programování je stále projektová činnost, není to konstrukce. Zápis testů jednotky poté, co skutečnost potvrdí, že kód dělá to, co dělá, ne že dělá něco užitečného. Selhání testu je skutečná hodnota, protože vám umožní včas zachytit chyby.

Kód je design

V kapitole 7 PPP "Strýček Bob" hovoří o tomto problému přímo. Velmi brzy v kapitole odkazuje na výborný článek od Jacka Reevese, ve kterém navrhuje, aby kód byl design (odkaz směřuje na stránku sbírající všechny tři jeho články na toto téma).

Na tomto argumentu je zajímavé, že na rozdíl od jiných inženýrských disciplín, kde je výstavba velmi nákladnou činností, je konstrukce softwaru relativně bezplatná (hit kompilace ve vašem IDE) a máte postavený Pokud vidíte psaní kódu jako konstrukční činnost namísto stavební činnosti, pak je cyklus červená-zelená-refaktoror v zásadě cvičení v designu. Váš návrh se vyvíjí, když píšete testy, kód je uspokojí a refaktor integrovat nový kód do existujícího systému.

TDD jako specifikace

Jednotkové testy, které píšete pro TDD, jsou přímým překladem specifikace, jak jim rozumíte. Tím, že napíšete kód, který minimálně vyhovuje vaší specifikaci (způsobí, že vaše testy zezelená), bude veškerý kód, který jste napsali, pro konkrétní účel. Zda byl tento účel splněn, je potvrzeno opakovatelným testem.

Zápis testů funkčnosti

Běžná chyba v testování jednotky se stane, když píšete testy za kódem, skončíte testováním, že kód dělá to, co dělá. Jinými slovy uvidíte testy jako je tento

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

I když myslím, že tento kód může být užitečný (ujistěte se, že někdo neudělal něco obscénního jednoduchou vlastností). Neslouží k ověření specifikace. A jak jste řekl, psaní těchto testů vás vezme jen tak daleko.

Zatímco zelená je dobrá, hodnota leží v červené barvě Měl jsem svůj první skutečný „aha“ okamžik v TDD, když jsem dostal nečekanou selhání testu. Měl jsem sadu testů, které jsem měl pro rámec, který jsem stavěl. Přidáním nové funkce jsem pro ni napsal test. Poté napsal kód, aby test proběhl úspěšně. Kompilace, test ... dostal nový test na zelenou. Ale také dostal červenou na další test, který jsem nečekal, že zbarví.

Když se podívám na selhání, vydechnu úlevou, protože pochybuji, že bych tuto chybu chytil docela dlouhou dobu, kdybych ten test neměl. A byla to velmi ošklivá chyba. Naštěstí jsem měl test a to mi přesně řeklo, co musím udělat, abych chybu opravil. Bez testu bych budoval svůj systém (s chybou infikující další moduly, které závisely na tomto kódu) a v době, kdy byla chyba objevena, by byl hlavním úkolem jej správně opravit.

Skutečnou výhodou TDD je to, že nám umožňuje provádět změny bezohledným opuštěním. Je to jako bezpečnostní síť pro programování. Přemýšlejte o tom, co by se stalo, kdyby lichoběžník udělal chybu a spadl. Se sítí je to trapná chyba. Bez, je to tragédie. Ve stejném ohledu vám TDD ušetří možnost proměnit chyby s kostí v katastrofy zabíjející projekty.

16
Michael Brown

Nenajdete nikoho, kdo obhajuje Test Driven Development, nebo dokonce Test Driven Design (jsou odlišné), což říká, že testy prokazují aplikace. Takže dovolte tomu jen říkat slaměný muž a být hotovo.

Nenajdete nikoho, kdo nemá rád TDD nebo na něj není dojem, že TDD říká, že testy jsou ztráta času a úsilí. Přestože testy neprokazují aplikace, jsou docela užitečné při hledání chyb.

S těmito dvěma věcmi bylo řečeno, že žádná ze stran nedělá nic jiného, ​​pokud jde o skutečné provádění testů na softwaru. Oba dělají testování. Oba RELY na testování najít tolik chyb, jak je to možné, a oba používají testy k ověření, že softwarový program funguje stejně jako lze zjistit v té době. Nikdo s polovinou vodítka neprodává software bez testování a nikdo s polovinou vodítka neočekává, že testováním bude kód, který prodávají, zcela bezchybný.

Rozdíl mezi TDD a TDD tedy není v tom, že se provádějí testy. Rozdíl je v tom, kdy jsou testy napsány. V TDD testech jsou psány PŘED software. V případě testů, které neprobíhají TDD, jsou psány po nebo ve shodě se softwarem.

Problém, který jsem viděl v souvislosti s posledně jmenovaným, spočívá v tom, že testování má tendenci zaměřit se na psaný software více, než je požadovaný výsledek nebo specifikace. I když je testovací tým oddělený od vývojového týmu, testovací tým inklinuje podívat se na software, hrát si s ním a psát testy, které na něj cílí.

Jednou z věcí, kterou si znovu a znovu všimli ti, kdo studují úspěšnost projektu, je to, jak často zákazník rozloží, co chce, vývojové utečou a něco napíší, a když se vrátí k zákazníkovi a řeknou „hotovo“ Ukázalo se, že to je naprosto a úplně NE, co zákazník požadoval. "Ale projde všemi testy ..."

Cílem TDD je prolomit tento „kruhový argument“ a poskytnout základ pro testy testující software, který není samotným softwarem. Testy jsou psány tak, aby se zaměřily na chování, které chce „zákazník“. Software je poté napsán, aby tyto testy vyhověl.

TDD je část řešení určeného k řešení tohoto problému. Není to jediný krok, který uděláte. Další věcí, kterou musíte udělat, je zajistit větší zpětnou vazbu od zákazníků a častěji.

Podle mých zkušeností je však TDD velmi obtížné úspěšně implementovat. Je těžké získat testy napsané dříve, než bude existovat produkt, protože mnoho automatizovaných testů vyžaduje něco, s čím si musí hrát, aby automatizační software fungoval správně. Je také obtížné přimět vývojáře, kteří na testování jednotek nejsou zvyklí. Znovu a znovu jsem řekl lidem v mém týmu, aby napsali testy PRVNÍ. Nikdy jsem jednoho nedostal, abych to udělal. Nakonec časová omezení a politika zničily veškeré úsilí, takže už ani neuskutečňujeme testy jednotek. To samozřejmě nevyhnutelně vede k tomu, že návrh byl náhodně a přísně spárován, takže i kdybychom to chtěli, implementace by byla nyní neúměrně nákladná. Vyhnout se, že to je to, co TDD nakonec poskytuje vývojářům.

11
Edward Strange

Navrhněte nejprve

TDD je ne omluva pro přeskočení návrhu. Viděl jsem mnoho skoků v „agilním“ rozjetém ​​voze, protože i když mohli okamžitě začít kódovat. Opravdová hbitost vás přivede k kódování statistik mnohem rychleji než (dobré praxe v jiných oborech), které inspirovaly proces vodopádu.

Ale vyzkoušejte brzy

Když někdo řekne, že test řídí projekt, znamená to jednoduše, že člověk může používat testy velmi brzy ve fázi návrhu, dlouho předtím, než je dokončen. Provedení těchto testů bude mít velký vliv na váš návrh tím, že zpochybní šedé oblasti a postaví je proti skutečnému světu dlouho před dokončením produktu. nutí vás často, abyste se vrátili k designu a upravili ho tak, aby to zohledňovalo.

Test a design ... jeden a stejný

Podle mého názoru TDD jednoduše přináší test, aby byl integrální součástí designu, místo něčeho, co se na konci udělá pro jeho ověření. Když začnete TDD používat stále více a více, dostanete se do myšlení, jak zničit/rozbít váš systém, jak jej navrhujete. Osobně ne vždy dělám testy nejprve. Jistě, že dělám zřejmé (unit) testy na rozhraní, ale skutečné zisky pocházejí z integračních a specifikačních testů, které vytvářím, když přemýšlím o novém a kreativním způsobu, jak tento design může zlomit. Jakmile vymyslím způsob, jak na to, vyzkouším a uvidím, co se stane. Někdy můžu žít s následkem, v tomto případě přesunu test do samostatného projektu, který není součástí hlavní budovy (protože bude i nadále selhat).

Tak kdo řídí show?

V TDD to znamená, že vaše testy jednoduše znamenají, že vaše testy ovlivňují váš návrh tak silně, že člověk může mít pocit, že ho skutečně řídí. To se však zastaví a tady chápu vaše obavy, je to trochu děsivé ... kdo řídí show?

VY jedete, ne testy. Testy jsou k dispozici tak, že jak budete postupovat, získáte dobrou úroveň důvěry v to, co jste vytvořili, což vám umožní dále budovat s vědomím, že spočívá na pevných základech.

pokud jsou testy pevné

Přesně, tedy řízený v TDD. Není to tolik, že testy řídí celou věc, ale budou mít tak hluboký vliv na to, jak děláte věci, na to, jak navrhujete a myslíte si svůj systém, že budete delegovat velkou část svého myšlenkového procesu na testy a na oplátku budou mít hluboký vliv na váš návrh.

jo, ale pokud to udělám s mým mostem ....

zastavte se přímo tam ... softwarové inženýrství je velmi odlišné od jiných inženýrských praktik tam. Softwarové inženýrství má ve skutečnosti mnohem víc společného s literaturou. Jeden může vzít hotovou knihu, vytrhnout 4 kapitoly z ní a napsat dvě nové kapitoly nahradit je držet je zpět v knize a stále máte dobrou knihu. Díky dobrým testům a softwaru můžete vytrhnout jakoukoli část vašeho systému a nahradit ji jinou, a náklady na to nejsou o mnoho vyšší, než když byl vytvořen. Ve skutečnosti, pokud jste provedli své testy a dovolili jim, aby dostatečně ovlivnili váš návrh, může být velmi dobře levnější než jej vytvořit na prvním místě, protože budete mít určitou úroveň jistoty, že tato náhrada nenaruší to, co testy pokrývají.

Pokud je jeho sooo dobrý, jak to, že to nefunguje vždy?

Protože testování vyžaduje VELMI odlišné myšlení než budování. Ne každý se dokáže přepnout zpět a od, ve skutečnosti někteří lidé nebudou schopni vytvořit správné testy jednoduše proto, že nemohou nastavit svou mysl, aby zničili jejich stvoření. To přinese projekty s příliš malým počtem testů nebo testů právě tak, aby bylo dosaženo cílových metrik (na mysli je pokrytí kódu). Budou rádi testy cest a výjimečné testy, ale zapomenou na rohové případy a okrajové podmínky.

Jiní se budou spoléhat pouze na testy předcházejícího designu částečně nebo úplně. Každý člen dělá to, co se děje, a pak se integruje s jedním jiným. Design je především komunikační nástroj, vsadili jsme se do země, abychom řekli, že to je místo, kde budu, náčrtky, které říkají, že to budou dveře a okna. Bez tohoto je váš software odsouzen k zániku bez ohledu na to, kolik testů do toho vložíte. Integrace a fúze budou vždy bolestivé a postrádají zkoušky na nejvyšší úrovni abstrakce.

Tor těchto týmů TDD nemusí být způsob, jak jít.

9
Newtopian

S TDD máte tendenci psát kód, který není snadné nebo rychlé otestovat. Může to vypadat jako malá věc, ale může to mít na projekt hluboký vliv, protože to ovlivňuje, jak snadné je refaktorovat, testovat, reprodukovat chyby pomocí testů a ověřovat opravy.

Je také snazší pro nového vývojáře v projektu, aby se dostali na rychlost, když máte lepší faktored kód podporovaný testy.

7
Alb

Hodně jsem o tom přemýšlel, přestože sám TDD tolik nepraktikuji. Zdá se, že existuje (silná?) Pozitivní korelace mezi kvalitou kódu a následným TDD.

1) Moje první snaha je, že to (především) není způsobeno tím, že TDD přidává do kódu „lepší kvalitu“ (jako takový), je to spíš, že TDD pomáhá odstraňovat nejhorší části a návyky, a tak nepřímo zvyšuje kvalitu.

Dokonce bych obhajoval, že to není samotný test - je to proces psaní těchto testů. Je těžké psát testy na špatný kód a naopak. A udržování tohoto v zadní části hlavy při programování eliminuje mnoho špatných kódů.

2) Dalším hlediskem (to se stává filozofickým) je sledování mentálních zvyků mistra. Naučíte se stát se mistrem sledováním jeho „vnějších zvyků“ (jako je dlouhý vous je dobrý), musíte se naučit jeho vnitřním způsobům myšlení, a to je těžké. A nějakým způsobem (začínající) programátoři sledují TDD, přizpůsobují své způsoby myšlení blíže těm, které mají mistři.

5
Maglob

Přístup "write test + refactor till pass" vypadá neuvěřitelně anti-inženýrství.

Zdá se, že máte mylnou představu o refaktoringu i TDD.

Refactoring kód je proces změny zdrojového kódu počítačového programu bez změny jeho vnějšího funkčního chování za účelem zlepšení některých nefunkčních atributů softwaru.

Takže nemůžete refaktoror kód, dokud to neprojde.

A TDD, konkrétně testování jednotek (což považuji za základní vylepšení, protože se mi zdá, že další test je pro mě docela pravděpodobné), není o přepracování komponenty, dokud nebude fungovat. Jde o návrh komponenty a práci na implementaci, dokud komponenta nebude fungovat tak, jak byla navržena.

Je také důležité pochopit, že jednotka testování je o testování jednotky. Vzhledem k tendenci neustále psát spoustu věcí od nuly, je důležité takové jednotky testovat. Stavební inženýr již zná specifikace jednotek, které používá (různé materiály), a může očekávat, že budou fungovat. To jsou dvě věci, které se často nevztahují na softwarové inženýry, a je velmi pro-engineering testovat jednotky před jejich použitím, protože to znamená použití testovaných, vysoce kvalitních komponent.
Pokud měl stavební inženýr nápad použít nějakou novou vláknovou tkáň pro výrobu střechy na pokrytí stadionu, očekávali byste, že ji otestuje jako jednotku, tj. Definuje potřebné specifikace (např. Hmotnost, propustnost, stabilita) atd.) a poté je otestujte a upravte, dokud se s nimi nesetká.

Proto TDD funguje. Protože pokud sestavujete software testovaných jednotek, šance jsou mnohem lepší, když to propojíte, a pokud ne, můžete očekávat, že problém bude v kódu lepidla, za předpokladu, že vaše testy mají dobré pokrytí.

úprava:
Refactoring znamená: žádná změna funkčnosti. Jedním bodem testu jednotky zápisu je zajistit, aby refaktoring neporušil kód. TDD má tedy zajistit, že refaktoring nemá vedlejší účinky.
Granularita není předmětem perspektivy, protože jak jsem řekl, jednotka testuje testovací jednotky a ne systémy, přičemž granularita je přesně definována.

TDD podporuje dobrou architekturu. Vyžaduje, abyste definovali a implementovali specifikace pro všechny své jednotky, což vás nutí navrhnout je před implementací, což je zcela v rozporu s tím, co si myslíte. TDD diktuje vytvoření jednotek, které mohou být testovány jednotlivě a jsou tedy zcela odděleny.
TDD neznamená, že jsem házel softwarový test na špagetový kód a míchal těstoviny, dokud to neprošlo.

Na rozdíl od stavebnictví se v softwarovém inženýrství projekt obvykle neustále vyvíjí. Ve stavebnictví máte požadavek postavit most v poloze A, který nese x tun a je dostatečně široký pro n vozidel za hodinu.
V softwarovém inženýrství se zákazník v zásadě může rozhodnout kdykoli (možná po dokončení), chce zdvojený most a chce, aby byl spojen s nejbližší dálnicí a aby si přál, aby to bylo zvedání most, protože jeho společnost nedávno začala používat plachetnice.
Softwaroví inženýři mají za úkol měnit návrhy. Ne proto, že by jejich návrhy byly chybné, ale proto, že je to modus operandi. Pokud je software dobře navržen, lze jej přepracovat na vysoké úrovni, aniž by bylo nutné přepisovat všechny komponenty nízké úrovně.

TDD je o vytváření softwaru s individuálně testovanými, vysoce oddělenými komponenty. Dobře provedené, pomůže vám reagovat na změny požadavků výrazně rychleji a bezpečněji, než bez nich.

TDD přidává požadavky do procesu vývoje, ale nezakazuje žádné jiné metody zajištění kvality. Je pravda, že TDD neposkytuje stejné zabezpečení jako formální ověření, ale znovu je formální ověření extrémně nákladné a nemožné jej používat na systémové úrovni. A přesto, pokud jste chtěli, můžete oba kombinovat.

TDD zahrnuje také testy jiné než jednotkové testy, které se provádějí na úrovni systému. Považuji je za snadno vysvětlitelné, ale obtížně proveditelné a těžko měřitelné. Také jsou docela věrohodné. I když naprosto vidím jejich nezbytnost, opravdu si je nevšímám jako myšlenek.

Nakonec žádný nástroj problém nevyřeší. Nástroje pouze usnadňují řešení problému. Můžete se zeptat: Jak mi dláto pomůže se skvělou architekturou? Pokud plánujete rovné zdi, pomáhají rovné cihly. A ano, je samozřejmé, že pokud dáte tomuto nástroji idiotovi, pravděpodobně ho nakonec zabouchne nohou, ale to není chyba sekáče, protože není vadou TDD, že to poskytuje falešné zabezpečení nováčkům, kteří nepíšou dobré testy.
Na spodním řádku tedy lze říci, že TDD funguje mnohem lépe než žádný TDD.

3
back2dos

Myslím, že se přibližujete k prvnímu bodu ze špatného úhlu.

Z teoretického hlediska dokazujeme, že něco funguje kontrolou proti bodům selhání. To je použitá metoda. Může existovat mnoho dalších způsobů, jak můžete dokázat, že něco je funkční, ale TDD se etabloval díky jednoduchosti svého bit-moudrého přístupu: pokud to nepřeruší, funguje to.

V praxi se to jen otevřeně projeví na: Nyní můžeme přejít k další věci (poté, co jsme úspěšně aplikovali TDD k uspokojení všech predikátů). Pokud přistupujete k TDD z této perspektivy, pak nejde o „napsat testy + refaktoror do úspěšného absolvování“, je to spíše o dokončení tohoto, nyní se plně soustředím na další funkci jako nyní nejvíce důležitá věc .

Přemýšlejte, jak to platí pro stavební inženýrství. Stavíme stadion, který pojme veřejné publikum 150000 lidí. Poté, co jsme dokázali, že strukturální integrita stadionu je dobrá, uspokojili jsme nejprve bezpečnost. Nyní se můžeme soustředit na další záležitosti, které se stávají okamžitě důležitými, jako jsou toalety, stánky s jídlem, sezení atd. ... a zpříjemňují tak zážitek publika. Jde o přílišné zjednodušení, protože TDD je mnohem více, ale klíčovým je to, že pokud se soustředíte na nové a vzrušující funkce a zároveň si zachováte integritu, neděláte to nejlepší možné uživatelské zážitky. V obou případech to dostanete na půl cesty. Jak tedy můžete přesně vědět jak mnoho záchodů a kam byste měli umístit 150000 lidí? Zřídka jsem viděl kolaps stadionů ve svém vlastním životě, ale musel jsem čekat v řadě během poločasu při tolika příležitostech. To znamená, že záchodový problém je patrně složitější, a pokud inženýři mohou strávit méně času bezpečností, budou konečně schopni vyřešit záchodovou otázku.

Váš druhý bod je irelevantní, protože jsme již souhlasili s tím, že absolutní věci jsou snaha bláznů , a protože Hank Moody říká, že neexistují (ale nemůžu najít odkaz na to).

2
Filip Dupanović

Nelíbí se mi, když říkáte, že „test spíše než uživatel nastavuje požadavek“. Myslím, že uvažujete pouze o testování jednotek v TDD, zatímco zahrnuje také testování integrace.

Kromě testování knihoven, které tvoří základ softwaru, pište testy, které pokrývají interakce vašich uživatelů se softwarem/webovou stránkou/cokoli. Ty pocházejí přímo od uživatelů a knihovny, jako je okurka (http://cukes.info), mohou dokonce uživatelům umožnit psát testy sami v přirozeném jazyce.

TDD také podporuje flexibilitu v kódu - pokud trávíte věčně navrhováním architektury něčeho, bude to neuvěřitelně těžké provést tyto změny později, bude-li to nutné. Začněte psát několik testů, pak napište malý kód, který tyto testy projde. Přidejte další testy, přidejte další kód. Pokud potřebujete kód radikálně změnit, vaše testy zůstanou v platnosti.

A na rozdíl od mostů a automobilů může jediný kus softwaru během své životnosti podstoupit obrovské změny a provádění složitých refaktoringů bez toho, aby byly nejprve napsány testy, je jen žádá kvůli problémům.

2
sevenseacat

Pokud přijmete, že čím dřívější chyby jsou nalezeny, tím menší jsou náklady na jejich opravu, pak to samo o sobě TDD vyplatí.

1
SnoopDougieDoug

TDD v softwarovém inženýrství je osvědčeným postupem, stejně jako zpracování chyb v aplikacích je osvědčeným postupem, protokolováním a diagnostikou (i když je to součástí zpracování chyb).

TDD nesmí být používán jako nástroj k omezení vývoje softwaru na kódování pokusů a chyb. Většina programátorů se však dívá na runtime protokoly, sleduje výjimky v debuggeru nebo používá jiné známky selhání/úspěchu během vývojové fáze, která spočívá v kódování/kompilaci/spuštění aplikace - po celý den.

TDD je jen způsob, jak formalizovat a automatizovat tyto kroky, aby vás jako vývojáře produktivnější.

1) Nemůžete porovnat softwarové inženýrství s mostní konstrukcí, flexibilita v mostní konstrukci není nijak blízká flexibilitě při navrhování softwarového programu. Konstrukce mostu je jako zapisování stejného programu znovu a znovu do ztrátového stroje. Můstky nelze duplikovat a znovu použít jako software. Každý most je jedinečný a musí být vyroben. Totéž platí pro automobily a jiné designy.

Nejobtížnější věcí v softwarovém inženýrství je reprodukování poruch, kdy když dojde k poruše mostu, je obvykle velmi snadné určit, co se pokazilo, a teoreticky je snadné selhání reprodukovat. Pokud počítačový program selže, může to být složitý řetězec událostí, který přinesl systém do chybného stavu a může být velmi obtížné určit, kde je chyba. TDD a jednotkový test usnadňují testování robustnosti softwarových komponent, knihoven a algoritmů.

2) Použití slabých jednotkových testů a mělkých testovacích případů, které nestresují systém k vytvoření falešného pocitu důvěry, je jen špatnou praxí. Ignorování architektonické kvality systému a pouze splnění testů jsou samozřejmě špatné. Ale podvádění na staveništi pro mrakodrap nebo most za účelem úspory materiálu a nedodržování plánů je stejně špatné a stále se to děje ...

1
Ernelli

Dám ti krátkou odpověď. TDD se obvykle dívá na nesprávný způsob stejně jako testování jednotek. Nikdy jsem nerozuměl testování jednotky až donedávna poté, co jsem viděl dobré tech talk video. TDD v podstatě jen říká, že chcete, aby následující věci fungovaly. MUSÍ být implementovány. Pak navrhnete zbytek softwaru tak, jak byste normálně.

Je to něco jako psaní případů použití knihovny před návrhem knihovny. Kromě toho můžete změnit případ použití v knihovně a možná ne pro TDD (pro návrh API používám TDD). Doporučujeme také přidat další test a přemýšlet o divokých vstupech/použitích, které může test získat. Považuji to za užitečné při psaní knihoven nebo API, kde pokud něco změníte, musíte vědět, že jste něco porušil. Ve většině každodenních programů se neobtěžuji, protože proč potřebuji testovací případ pro uživatele stiskem tlačítka nebo pokud chci přijmout seznam CSV nebo seznam s jedním záznamem na řádek ... Na tom opravdu nezáleží Chcete-li to změnit, tak bych neměl/převýšení používat TDD.

0
user2528

Proč TDD funguje?

To ne.

Objasnění: automatizované testy jsou lepší než žádné testy. Osobně si však myslím, že většina jednotkových testů je plýtváním, protože obvykle tautologicky (tj. Říká věci zřejmé ze skutečného testovaného kódu) a nelze snadno dokázat, že jsou konzistentní, nejsou nadbytečné a pokrývají všechny případy na hranicích (kde se obvykle vyskytují chyby) ).

A co je nejdůležitější: Dobrý softwarový design magicky nevyplývá z testů, protože je propagován mnoha agilními/TDD evangelisty. Každý, kdo tvrdí jinak, uveďte odkazy na recenzovaný vědecký výzkum, který to dokazuje, nebo alespoň odkaz na nějaký projekt s otevřeným zdrojovým kódem, kde lze výhody TDD potenciálně studovat podle historie změn kódu.

0
KolA

TDD ve skutečnosti není o testování. A rozhodně to není náhrada za dobré testování. To, co vám dává, je design, který je dobře promyšlený, snadno spotřebovatelný a snadno udržovatelný a refaktorující později. Tyto věci zase vedou k menšímu počtu chyb a lepšímu, přizpůsobivějšímu návrhu softwaru. TDD vám také pomůže promyslet a zdokumentovat vaše předpoklady, často zjistí, že některé z nich byly nesprávné. Zjistíte to velmi brzy v tomto procesu.

A jako příjemná vedlejší výhoda máte velkou sadu testů, které můžete spustit, abyste se ujistili, že refaktoring nemění chování (vstupy a výstupy) vašeho softwaru.

0
Marcie

Software je organický, když je konstrukční inženýrství konkrétní.

Když stavíte svůj most, zůstane to most a je nepravděpodobné, že se během krátké doby vyvine v něco jiného. Vylepšení budou prováděna v průběhu měsíců a let, ale ne hodin a dní jako v softwaru.

Když testujete izolovaně, můžete normálně použít dva typy rámců. Omezený rámec a neomezený. Neomezené rámce (v .NET) vám umožňují testovat a nahrazovat vše bez ohledu na modifikátory přístupu. Tj. můžete zakázat a zesměšňovat soukromé a chráněné komponenty.

Většina projektů, které jsem viděl, používá omezené rámce (RhinoMocks, NSubstitute, Moq). Při testování pomocí těchto rámců musíte navrhnout aplikaci tak, aby bylo možné za běhu aplikovat a nahrazovat závislosti. To znamená, že musíte mít volně spojený design. Volně vázaný design (je-li proveden správně) znamená lepší oddělení zájmů, což je dobrá věc.

Abych to shrnul, věřím, že za tím stojí myšlenka, že pokud je váš návrh testovatelný, je to volně spojené a má dobré oddělení zájmů.

Na vedlejší poznámku jsem viděl aplikace, které byly skutečně testovatelné, ale špatně napsané z objektově orientovaného designu.

0
CodeART