it-swarm-eu.dev

Dokážete být agilní, aniž byste dělali TDD (testem řízený vývoj)?

Je možné správně nazvat sebe (nebo váš tým) „agilním“, pokud neděláte TDD (Test-Driven Development)?

44
CraigTP

Ano, ano, ano, milionkrát ano.

Agilní je filozofie, TDD je specifická metodologie.

Kdybych chtěl být opravdu vybíravý, mohl bych jednoduše poukázat na to, že existuje několik variant xDD - které jejich zastánci vysvětlí do hloubky, nejsou ne TDD - ale ty jsou stále v podstatě spojeny s testem jako první, takže by to bylo podvádění.

Řekněme to takto - můžete být agilní, aniž byste museli provádět „test první“ vývoj (podívejte se na to, jak funguje scrum - nikde tam nejsou specifika, jak píšete kód). Podívejte se na nástěnku Kanban, podívejte se na nejrůznější agilní metody.

Chcete testy jednotek? Samozřejmě, že děláte ze všech důvodů - a můžete argumentovat, že bez jednotkových testů nemůžete být agilní (i když mám podezření, že můžete být) - ale nemusíte je nejdříve psát, abyste byli agilní.

A konečně, je stejně pravda, že byste mohli udělat Test First , aniž byste byli Agilní a silné argumenty pro provedení testu nejprve bez ohledu na vaši celkovou dev filozofii.


Zdá se, že ostatní (s více SOLID rep) mají podobný názor ...

http://www.Twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Ačkoli není možné dělat Agile bez TDD a OOD, je to obtížné. Bez TDD je iterační rychlost ...

(Odkaz v Tweetu je na úplnou odpověď na LinkedIn)

50
Murph

„Být agilní“ znamená jednoduše dodržovat hodnoty a zásady agilní manifest . Nic v tomto dokumentu nezmiňuje TDD nebo dokonce testování jednotek v této záležitosti.

Takže ano, můžete být agilní, aniž byste museli provádět TDD nebo testování jednotek.

Přesto bych to nedoporučoval ...

19
Martin Wickman

Ano,

Podívejte se na jednu z agilních hodnot:

Jednotlivci a interakce přes procesy a nástroje

To by už mělo odpovědět. TDD je určitá metodologie, proces. Opravdu proces, který by mohl být použit v agilních vývojových procesech, ale nic víc. Myslím, že TDD je možná nejmodernější, když je agilní. Domnívám se však, že koncept agility bude stále trvat, i když možná byl TDD nahrazen jinými postupy.

Shrnul bych to takto:

  • Dnes TDD je defacto-standard pro to, aby byl agilní

  • Mohou existovat způsoby, jak být agilní bez TDD

11
FabianB

Říkám

Žádný [druh]

Pokud se vrátíte k původnímu zdroji http://en.wikipedia.org/wiki/Extreme_Programming TDD je pro tento proces zásadní; testy nahrazují specifikace požadavků a případy použití vodopádu, slouží jako živá dokumentace a funkční příklady atd. Jsou nezbytné.

Nyní však existuje tolik různých příchutí „agilního“ vznášejícího se kolem, že je zcela možné, že jedna z nich unikne TDD

EDIT: @ Murphova interpretace otázky se zdá být preferovaná. Sakra, dokonce jsem to vylepšil, je to dobrá odpověď. Nicméně, trvám na svém stanovisku, že Agilní manifest je soubor zásad, nikoli rozvojová metodologie. Nevidím nic užitečného, ​​když říkám „ach ano, jsem agilní“, aniž bych skutečně implementoval postupy, které přinášejí výhody. Zejména:

Pracovní software je primárním měřítkem pokroku.

a

Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři a uživatelé by měli být schopni udržovat konstantní tempo po neomezenou dobu.

Pro mě tyto dva principy znamenají, pokud nevyžadují TDD - alespoň nevím o žádném jiném způsobu, jak je dosáhnout bez toho!

ÚPRAVA 2: ano, technicky můžete testy následně napsat; ale stále považuji test-first/TDD za základní. Ne proto, že bez ní nebudete „agilní“, ale protože s tím budete více agilní. Test-first/test-driven je mnohem účinnější přístup než test-later/test-afterthought. Popisy testů jsou požadavky. Nevkládejte je později ;-)

EDIT 3: Konečně jsem přišel na to, co mě tolik vadí Murphově velmi dobře napsané odpovědi. Je to představa, že by člověk mohl být „Agilní“, aniž by ve skutečnosti dělal. A „dělat to“ (jak je ukázáno výše) do značné míry vyžaduje TDD.

5
Steven A. Lowe

Můžete být agilní, ale pravděpodobně existuje prostor pro zlepšení.

Jedním z principů agility je, že musíte být schopni reagovat na změny. To znamená, že nevím předem, co musíte stavět. Pokud byste postupovali po vodopádu, měli byste předem vědět, co přesně potřebujete, a co byste měli sestavit, a mohli byste navrhnout jednotlivé softwarové komponenty tak, aby se každý z nich zúčastnil nějakého většího schématu a dosáhl finálního produktu (alespoň byste si mysleli, že bylo to tak). Ale protože agilní diktuje, že nevíte, co je konečný produkt, nikdy nevíte, pro co bude kód použit, a co je důležitější, kdy bude změněn.

Proto potřebujete důkladnou testovací sadu, abyste se ujistili, že funkce, které jste již vytvořili, budou i po úpravě kódové základny fungovat.

Ale to samo o sobě není TDD. Pokud zapíšete testy po napsání kódu, nejedná se o TDD. Ale TDD pomáhá s jiným aspektem, zabraňuje nadprodukci.

Ve svém vlastním agilním týmu jsem bojoval s vývojáři, kteří psali kód, o kterém se domnívají, že by se později v projektu stal užitečným. Kdyby to byl vývoj vodopádů, byl by pravděpodobně v pořádku, protože přidávali podporu pro něco v plánu projektu na příštích x měsíců.

Pokud však dodržujete agilní principy, neměli byste tento kód psát, protože nemáte ponětí, zda to bude dokonce nutné. Funkce, která byla naplánována na příští týden, může být najednou odložena na neurčito.

Pokud správně dodržujete princip TDD, pak jediný řádek kódu nemůže existovat dříve, než test diktuje tento řádek kódu (osobně mohu napsat nějaký triviální kód bez testování), a pokud začnete psáním akceptačního testu, pak implementujete pouze přesně to, co je potřeba k dodání požadovaných funkcí.

TDD tedy pomáhá vyhnout se nadprodukci a umožňuje týmu být co nejefektivnější, což je také základní agilní princip.

Pracovní software je primárním měřítkem pokroku

2
Pete

Přísně jste agilní dodržováním agilní manifest . V praxi není kódová základna pohyblivá, pokud nemá dobré pokrytí testem. Můžete provádět TDD a psát testy před/během vývoje funkčnosti nebo psát testy funkčnosti po jejím vývoji. Obvykle je však snazší a efektivnější to udělat způsobem TDD.

2
Alb

Dokážete být agilní, aniž byste dělali TDD (testem řízený vývoj)?

Krátká odpověď: Ano.

Delší odpověď: Na tuto otázku již existuje mnoho opravdu dobrých odpovědí a velmi dobré reference. Nebudu se pokoušet o těchto bodech diskutovat.

Podle mých zkušeností je Agile o výběru správné úrovně štíhlosti pro daný projekt. Co tím myslím Lean-ness? A proč to uvedu v této odpovědi?

Lean neznamená sekání všeho možného z vaší metody. Jak poznamenal jeden z našich kolegů, do svého chování nemusíte zahrnovat TDD nebo Unit Test. V kontextu projektu se však ocitnete, může to nebo nemusí být prospěšné.

Pojďme se zamyslet nad dodavatelským řetězcem velkého nepojmenovaného maloobchodníka se sídlem v AK. Je tu spotřebitel. Jdou do obchodu. Obchod přijímá různé produkty prostřednictvím kamionu. Kamiony pravděpodobně získají tyto výrobky ze skladu. Sklad je naplněn zásilkami od různých výrobců. Výrobci zase mají celé řetězce zásobování sami.

Co se stane, když generálnímu řediteli pro přepravu ve výše uvedeném dodavatelském řetězci bude řečeno, že za každý rok dostane roční bonus 1 milion dolarů, že má ve vozovém parku méně než 10 nákladních vozidel? Okamžitě naseká flotilu na 9 nákladních vozidel. V tomto „hrozném“ scénáři to zvýší množství zboží uloženého ve skladu (zvýšení nákladů v tomto uzlu). A to bude "hladovět" přední fronty.

Celkový dodavatelský řetězec tedy trpí, pokud je povolena lokální optimalizace bez ohledu na celek.

Zpět na TDD a UT. TDD je mechanismus exprese požadavků. Systém MUSÍ splňovat tato omezení. Dost spravedlivé. TDD může nahradit chování požadavků na použití Case Drive Development nebo chování požadavků poháněných vývojem User Story. Výhodou „naklánění“ je kombinace pracovní zátěže Unit Test a požadavky. Výhodou je snížení celkové pracovní zátěže. Není tomu tak, pokud se zvýší celková pracovní zátěž dodavatelského řetězce (pojďme opravit kvalitu).

A tak jste se zeptali: Můžete být agilní, aniž byste dělali TDD (testem řízený vývoj)?

Jasně že můžeš. Jiná a možná lepší otázka zní: - Pokud na tento projekt použiji TDD, bude to mít za následek celkově efektivnější dodání softwaru nebo méně efektivní?

Citovat oblíbeného autora ... J.R.R. Tolkien

Pán prstenů. Společenstvo prstenů. Str. 94 „A také se říká,“ odpověděl Frodo: „Nejděte k elfům za radu, protože oni ne a ano.“

Nakonec ... záleží. Musíte odpovědět na otázku. Která cesta vás nejefektivněji dovede k požadovaným cílům.

Na TDD nebo ne na TDD. To zůstává otázkou. :-)

PS - Tuto odpověď zjišťuji i na jiném webu. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

1
M Kevin McHugh

Ve srovnání s inženýrstvím hradu.

Agilní hrad

Kdybyste měli připravit hrad pomocí Agile. Psali byste části, které mají specifické funkce, a povzbuzovali uživatele k používání funkčních částí a přizpůsobovali budoucí design reakcím uživatele. Takže stavíte žalář a komunikujete s ochráncem žaláře, vyzkoušíte nadaci poskytovanou zemí a žalářem. Postavili byste parapety a zeptali se nočních hlídačů, jestli je to dobré. Postavili byste zdi a nechali vojáky vyzkoušet obrannou hodnotu. Postavili byste kuchyň a nechali kuchaře, aby si ji prohlédli. A během tohoto procesu by každá současná část fungovala vedle aktuální struktury. Když jste skončili v žaláři, mohli jste zajatce dovnitř. A tak dále. Když ale konečně dokončíte hrad, zjistíte, že vězni unikli. Nyní se musíte vrátit do vězení a zjistit, že potřebujete tlustší tyče, ale dveře nejsou dostatečně hluboké, aby držely tyče, a závěsy nepodporují větší dveře.

TDD Castle

S TDD se ukážete s vězněmi a uvidíte, zda uniknou. Pak píšete vězení, dokud nemohou uniknout. Pak byste kód upravili tak, že čistě odstraníte nepotřebné buňky a odstraníte pruhy, které jsou na nesprávném místě, a znovu otestujte. Vězni neunikli. S jailor nemusíte komunikovat. A mohl byste dodat celý hrad, jakmile to všechno dokončíte. V tu chvíli jailor říká, že dungeon potřebuje více buněk, a teď musíte vykopat více nadace.

Agilní hrad TDD

Pokud kombinujete Agile a TDD. Uvidíte, jestli vězni unikli, a zeptejte se jailor, co je potřeba. Říká, že potřebujete více buněk. Chytil bys nějaké náhodné lidi, aby předstíral, že jsou vězni, a uvidíš, jestli uniknou. Pokud tomu tak není, ukážete to jailorovi a on je s tím spokojený. Pak začnete stavět parapety.

Závěr

Oba tedy řeší různé problémy. Agile pomáhá s měnícími se požadavky na základě objevování potřeb uživatelů, protože vidí vývoj produktu v okamžiku, kdy je nejjednodušší přizpůsobit se. Jedná se o uvolnění stabilních doplňků rozdělených z celkového designu.

TDD řeší problém předvídání selhání. Zjištění a náprava selhání, ke kterému dojde v okamžiku, kdy je nejjednodušší opravit. Zahrnuje testování stabilních odpojených jednotek kódu rozdělených z celkového návrhu.

Je snadné vidět TDD jako rozšíření Agile, protože oba sledují stejný vzorec, postup a hodnocení řízené jednotkou. Rozdíl je v tom, že jednotky v Agile fungují externě až dosud jako celek, zatímco jednotky v TDD fungují jako součást a nemusí produkovat funkční produkt pro externí kontrolu. A oba procesy řídí různé potřeby (použitelnost vs. správnost). Protože oba fungují nad procesem vývoje v jednotkách, mohou se oba revizní procesy vyskytovat v podobných bodech, přičemž TDD je jemněji rozdělena.

Poznámky

  • Samotné testování jednotek neznamená, že používáte TDD. TDD znamená mít test před vyrobenou jednotkou a použít test, jak se vyvíjíte, k potvrzení jednotky. Testování jednotek bez TDD lze použít k tomu, abyste se ujistili, že neporušujete dříve vytvořené funkce.
  • Mít sprinty a další schůzky vás nezbavuje agility. Cíle manifestu vás činí agilním. Cíle vodopádu můžete rozdělit na sprinty s pracovními jednotkami, aniž byste splnili závazek upřednostňovat lidi před procesy.
  • Podle definice TDD a Agile. Vaše testy jednotek budou řídit nedostupné jednotky, a tak TDD bude jezdit rychleji než Agile. A pokud použijete oba, vaše Agilní cykly budou obsahovat jeden nebo více TDD cyklů (pokud je testována každá jednotka).
  • Z toho, co chápu: Agile selete tím, že se vám nepodaří vyvinout doručitelnou/smysluplnou jednotku pro uživatele. Jednotka může mít smysl, i když zrychluje produkt. Jak ale Agile vysvětluje refaktoring pro snadnější údržbu? Nezakryl jsem to dost, abych na to odpověděl.
  • Selháte TDD selháním testu jednotky. Vytváří kód, který tuto funkci nevytváří správně.
1
Lee Louviere

Agilní vás nutí řešit a zmírňovat rizika spojená s plánem a kvalitou při každé iteraci. tj. TDD není nutné považovat za agilní.

TDD je však obrovská technika pro zmírnění rizik kvality, zejména pro projekt s velkým počtem iterací nebo lidí. V takovém projektu TDD přidá určité riziko plánu v časných iteracích, protože musíte také napsat testovací případy. TDD však v pozdějších iteracích přináší obrovské úspory nákladů, protože neustále snižuje rizika kvality. tj. TDD se doporučuje.

0
Jay Godse