it-swarm-eu.dev

Funguje TDD opravdu pro složité projekty?

Ptám se na tuto otázku ohledně problémů, se kterými jsem se setkal během TDD projektů. Při vytváření testů jednotek jsem si všiml následujících výzev.

  • Generování a údržba falešných dat

Je těžké a nereálné udržovat velké falešné údaje. Je to ještě těžší, když se změní struktura databáze.

  • Testování GUI

Dokonce s MVVM a schopností testovat GUI, to trvá hodně kódu reprodukovat scénář GUI.

  • Testování firmy

Mám zkušenosti, že TDD funguje dobře, pokud jej omezíte na jednoduchou obchodní logiku. Je však obtížné otestovat složitou obchodní logiku, protože počet kombinací testů (testovací prostor) je velmi velký.

  • Rozpor v požadavcích

Ve skutečnosti je těžké zachytit všechny požadavky analyzované a navržené. Požadavky jedné poznámky často vedou k rozporu, protože projekt je složitý. Rozpor je nalezen pozdě ve fázi implementace. TDD vyžaduje, aby požadavky byly 100% správné. V takových případech lze očekávat, že při vytváření testů budou zachyceny protichůdné požadavky. Problém je však v tom, že tomu tak není ve složitých scénářích.

Přečetl jsem tuto otázku: Proč TDD funguje?

Funguje TDD opravdu pro složité podnikové projekty, nebo je prakticky omezen na typ projektu?

53
Amir Rezaei

Je těžké a nereálné udržovat velké falešné údaje. Je to ještě těžší, když se změní struktura databáze.

Nepravdivé.

Testování jednotek nevyžaduje „velká“ falešná data. Vyžaduje dostatek falešných dat k testování scénářů a nic víc.

Opravdu líní programátoři také žádají odborníky, aby vytvořili jednoduché tabulky různých testovacích případů. Jen jednoduchá tabulka.

Pak líný programátor píše jednoduchý skript pro transformaci řádků tabulky na případy testování jednotek. Je to docela jednoduché, opravdu.

Při vývoji produktu se aktualizují tabulky testovacích případů a generují se nové testy jednotek. Udělej to pořád. Opravdu to funguje.

I s MVVM a schopností testovat GUI je pro reprodukci scénáře GUI zapotřebí hodně kódu.

Co? "Reprodukovat"?

Smyslem TDD je navrhnout věci pro testovatelnost (Test Drive Development). Pokud je grafické rozhraní tak složité, musí být přepracováno tak, aby bylo jednodušší a testovatelnější. Jednodušší také znamená rychlejší, udržovatelnější a flexibilnější. Ale většinou jednodušší bude znamenat více testovatelných.

Mám zkušenosti, že TDD funguje dobře, pokud jej omezíte na jednoduchou obchodní logiku. Komplexní obchodní logiku je však obtížné otestovat, protože počet kombinací testu (testovací prostor) je velmi velký.

To může být pravda.

Žádat odborníky na předmět, aby poskytli základní testovací případy jednoduchou formou (jako je tabulka), však opravdu pomáhá.

Tabulky mohou být poměrně velké. Ale to je v pořádku, protože jsem použil jednoduchý skript Python) k přeměně tabulek na testovací případy.

A. Některé testovací případy jsem musel psát ručně, protože tabulky byly neúplné.

Nicméně. Když uživatelé nahlásili „chyby“, jednoduše jsem se zeptal, který testovací případ v tabulce byl špatný.

V tu chvíli odborníci na předmět upravili tabulku nebo přidali příklady vysvětlující, co se mělo stát. Hlášení chyb lze - v mnoha případech - jasně definovat jako problém s testovacím případem. Skutečně, z mé zkušenosti, definování chyby jako zlomeného testovacího případu diskusi mnohem, mnohem jednodušší.

Spíše než poslouchat odborníky se snaží vysvětlit velmi složitý obchodní proces, musí odborníci předložit konkrétní příklady tohoto procesu.

TDD vyžaduje, aby požadavky byly 100% správné. V takových případech lze očekávat, že při vytváření testů budou zachyceny protichůdné požadavky. Problém je však v tom, že tomu tak není v případě složitého scénáře.

Nepoužívání TDD absolutně nařizuje, aby požadavky byly 100% správné. Někteří tvrdí, že TDD může tolerovat neúplné a měnící se požadavky, kde přístup bez TDD nemůže fungovat s neúplnými požadavky.

Pokud TDD nepoužíváte, je rozpor nalezen pozdě ve fázi implementace.

Pokud používáte TDD, je rozpor nalezen dříve, když kód projde některými testy a selže jiné testy. TDD vám skutečně dává důkaz rozporu dříve v tomto procesu, dlouho před implementací (a argumenty během testování přijatelnosti uživatele).

Máte kód, který projde některými testy a ostatní selže. Díváte se na pouze ty testy a zjistíte rozpor. Funguje to opravdu, opravdu dobře v praxi, protože nyní se uživatelé musí hádat o rozporu a vytvářet konzistentní, konkrétní příklady požadovaného chování.

52
S.Lott

Ano

Moje první expozice TDD byla práce na komponentách middleware pro mobilní telefon založený na Linuxu. To nakonec skončilo miliony řádků zdrojového kódu, což zase vyvolalo asi 9 gigabajtů zdrojového kódu pro různé komponenty s otevřeným zdrojovým kódem.

Od všech autorů komponent se očekávalo, že navrhnou API a sadu jednotkových testů a nechají je zkontrolovat návrh kolegiální komisí. Nikdo neočekával dokonalost při testování, ale všechny veřejně exponované funkce musely mít alespoň jeden test a jakmile byla komponenta podrobena řízení zdroje, všechny testy jednotek musely vždy projít (i když tak učinily, protože komponenta chybně hlásila zprávy) fungovalo to dobře).

Není pochyb o tom, že přinejmenším částečně TDD a naléhání, že všechny testy jednotek vždy projdou, vydání 1.0 přišlo brzy, pod rozpočtem a s úžasnou stabilitou.

Po vydání verze 1.0, protože společnost chtěla být schopna rychle změnit rozsah kvůli požadavkům zákazníků, řekli nám, abychom přestali dělat TDD, a odstranili požadavek, který testy jednotek projdou. Bylo úžasné, jak rychle kvalita klesla na toaletu, a pak ji dodržoval plán.

28
Bob Murphy

Tvrdil bych, že čím je projekt složitější, tím větší výhody získáte z TDD. Hlavními výhodami jsou vedlejší účinky toho, jak vás TDD přinutí napsat kód v mnohem menších, mnohem nezávislejších blocích. Klíčové výhody jsou:

a) Získáte mnohem, mnohem dřívější validaci svého návrhu, protože vaše zpětná vazba je díky testům z go go mnohem těsnější.

b) Můžete měnit kousky a kousky a sledovat, jak systém reaguje, protože jste neustále vytvářeli přikrývku testovacího pokrytí.

c) Výsledný kód bude v důsledku toho mnohem lepší.

18
Wyatt Barnett

Funguje TDD opravdu pro složité projekty?
Ano. Ne každý projekt, takže mi bylo řečeno, funguje dobře s TDD, ale většina obchodních aplikací je v pořádku a vsadím se, že ty, které nefungují dobře, když jsou psány čistě TDD, by mohly být psány ATDD způsobem bez větších problémů.

Generování a údržba falešných dat
Zachovejte to malé a mějte pouze to, co potřebujete, a to není strašidelný problém, jak se zdá. Nechápejte mě špatně, je to bolest. Ale stojí to za to.

Testování GUI
Otestujte MVVM a ujistěte se, že lze testovat bez výhledu. Zjistil jsem, že to není o nic těžší než testování jakékoli jiné logiky podnikání. Testování zobrazení v kódu Neudělám, vše, co testujete, je v tomto bodě závazná logika, která, jak doufáme, se rychle zachytí, když provedete rychlý ruční test.

Testování firmy
Nebyl zjištěn problém. Spousta malých testů. Jak jsem řekl výše, některé případy (Sudoku puzzle řešitelé se zdají být populární) jsou zřejmě obtížné udělat TDD.

TDD vyžaduje, aby požadavky byly 100% správné
Ne to není. Odkud jsi dostal tento nápad? Všechny agilní praktiky akceptují změnu požadavků. Než to uděláte, musíte vědět, co děláte, ale to není totéž, co vyžaduje, aby požadavky byly 100%. TDD je běžnou praxí v Scrumu, kde požadavky (uživatelské příběhy) nejsou ze své definice 100% úplné.

10
mlk

Za prvé, domnívám se, že váš problém se týká spíše testování jednotek než TDD, protože v tom, co říkáte, nevidím ve skutečnosti nic specifického pro TDD (test-první + červený-zelený-refaktorový cyklus).

Je těžké a nereálné udržovat velké falešné údaje.

Co myslíš falešnými daty? Zesměšňovač přesně předpokládá, že neobsahuje téměř žádná data, tj. Žádná jiná pole než jedno nebo dvě pole potřebná pro test a žádné jiné závislosti než testovaný systém. Nastavení falešných očekávání nebo návratové hodnoty lze provést na jednom řádku, takže nic hrozného.

Je to ještě těžší, když se změní struktura databáze.

Pokud máte na mysli, že databáze prochází změnami, aniž by byly provedeny správné úpravy objektového modelu, jsou zde právě testy jednotek, které vás na to upozorní. Jinak se změny modelu musí zjevně projevit v jednotkových testech, ale u kompilačních indikací je to snadné.

Dokonce s MVVM a schopností testovat GUI, to trvá hodně kódu reprodukovat scénář GUI.

Máte pravdu, testování jednotky GUI (View) není snadné a mnoho lidí se bez ní daří dobře (kromě toho testování GUI není součástí TDD). Na rozdíl od toho se testování jednotky Controller/Presenter/ViewModel/jakákoli mezivrstva vysoce doporučuje, ve skutečnosti je to jeden z hlavních důvodů, proč jsou vzory jako MVC nebo MVVM.

Mám zkušenosti, že TDD funguje dobře, pokud jej omezíte na jednoduchou obchodní logiku. Je však obtížné otestovat složitou obchodní logiku, protože počet kombinací testů (testovací prostor) je velmi velký.

Pokud je vaše obchodní logika složitá, je normální, že testy jednotek je obtížné navrhnout. Je jen na vás, abyste je učinili co možná atomově atomičtější, přičemž každý testoval pouze jednu odpovědnost za testovaný objekt. Jednotkové testy jsou o to více potřebné ve složitém prostředí, protože poskytují bezpečnostní síť zaručující, že při provádění změn kódu nebudete porušovat obchodní pravidla nebo požadavky.

TDD vyžaduje, aby požadavky byly 100% správné.

Rozhodně ne. Úspěšný software vyžaduje, aby požadavky byly 100% správné;) Testy jednotek pouze odrážejí vaši vizi požadavků; pokud je vize chybná, váš kód a váš software budou také, testy jednotek nebo ne ... A to je místo, kde testy jednotek svítí: s dostatečně explicitními názvy testů se vaše návrhová rozhodnutí a interpretace požadavků stanou průhlednými, což usnadňuje orientaci prstem na to, co je třeba změnit, až váš zákazník řekne: „toto obchodní pravidlo není tak, jak bych chtěl“.

9
guillaume31

Musím se smát, když slyším někoho, jak si stěžuje, že důvod, proč nemohou použít TDD k testování jejich aplikace, je proto, že jejich aplikace je tak komplikovaná. Jaká je alternativa? Už testovací opice buší na akry klávesnic? Nechte uživatele být testery? Co jiného? Samozřejmě je to těžké a složité. Myslíte si, že Intel netestuje jejich čipy, dokud nebudou dodány? Jak je to „hlava v písku“?

6
SnoopDougieDoug
> Does TDD really work for complex projects?

Z mé zkušenosti: Ano pro Unittests (test modulů/funkcí izolovaně), protože tyto většinou nemají problémy, které zmiňujete: (Gui, Mvvm, Business-Modell). Nikdy jsem neměl více než 3 falešné/výhonky, abych vyplnil jednu nejjednotnější zkoušku (ale možná vaše doména vyžaduje více).

Jsem ale ne shure, pokud TDD dokáže vyřešit problémy, které jste zmínili o integraci nebo end-to-end testování pomocí testů ve stylu BDD.

Ale alespoň některé problémy lze snížit.

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

To platí, pokud chcete provést úplné pokrytí na úrovni testu integrace nebo testu end-to-end. Může být snazší provést úplné pokrytí na nejjednotnější úrovni.

Příklad: Kontrola složitých uživatelských oprávnění

Testování funkce IsAllowedToEditCusterData() na úrovni integračního testu by vyžadovalo požádat různé objekty o informace o uživateli, doméně, zákazníkovi, prostředí .....

Zesměšňování těchto částí je poměrně obtížné. To platí zejména v případě, že IsAllowedToEditCusterData() musí znát tyto různé objekty.

Na úrovni Unittest byste měli funkci IsAllowedToEditCusterData(), která vezme například 20 parametrů, které obsahují vše, co funkce potřebuje znát. Jelikož funkce IsAllowedToEditCusterData() nemusí vědět, jaká pole user, domain, customer, .... je snadné ji otestovat.

Když jsem musel implementovat IsAllowedToEditCusterData(), měl jsem dvě přetížení:

Jedno přetížení, které neudělá nic jiného než získání těchto 20 parametrů, a poté vyvolání přetížení s 20 parametry, které rozhodují.

(moje IsAllowedToEditCusterData() měla pouze 5 parametrů a pro testování jsem potřebovala 32 různých kombinací)

Příklad

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}
4
k3b

Zjistil jsem, že TDD (a testování jednotek obecně) je prakticky nemožné z souvisejících důvodů: Složité, nové a/nebo fuzzy algoritmy. Ve výzkumných prototypech, které píšu, se nejčastěji setkávám s problémem, že netuším, jaká je správná odpověď, než spuštěním kódu. Je příliš složité na to, aby se rozumně vymýšlely ručně, na nic jiného než směšně triviální případy. To platí zejména v případě, že algoritmus zahrnuje heuristiku, aproximace nebo nedeterminismus. Stále se snažím otestovat funkčnost nižší úrovně, na které tento kód závisí, a tvrdě používám tvrzení při kontrole rozumnosti. Moje poslední metoda testování je napsat dvě různé implementace, ideálně ve dvou různých jazycích pomocí dvou různých sad knihoven a porovnat výsledky.

4
dsimcha

Smutnou odpovědí je, že pro velké složité projekty nic nefunguje!

TDD je stejně dobrý jako cokoli jiného a lepší než většina ostatních, ale samotný TDD nezaručuje úspěch ve velkém projektu. To však zvýší vaše šance na úspěch. Zejména při použití v kombinaci s jinými disciplínami řízení projektů (ověřování požadavků, případy použití, matice sledovatelnosti požadavků, průchodky kódu atd.).

3
James Anderson

Viděl jsem, že velký složitý projekt zcela selhal, když byl TDD používán výhradně, tj. Aniž by se alespoň nastavovalo v debuggeru/IDE. Falešná data a/nebo testy se ukázaly jako nedostatečné. Reálná data klientů Beta byla citlivá a nemohla být zkopírována ani zaznamenána. Dev tým tedy nikdy nemohl opravit fatální chyby, které se projevily, když ukazoval na reálná data, a celý projekt byl sešrotován, všichni vystřelili, celý bit.

Způsob, jak tento problém napravit, by bylo vypálit ho v debuggeru na klientském webu, žít proti skutečným datům, procházet kódem, s body přerušení, sledovacími proměnnými, pamětí hodinek atd. Tento tým, kteří si mysleli, že jejich kód je vhodný k ozdobení nejlepších věží ze slonoviny, po dobu téměř jednoho roku jejich aplikaci nikdy nevystřelili. To mi vyhodilo mysl.

Stejně jako všechno je rovnováha klíčem. TDD může být dobrý, ale nespoléhejte se na něj výhradně.

1
SPA

Nezapomeňte, že testy jednotek jsou vynucené specifikace. To je zvláště cenné ve složitých projektech. Pokud vaše stará kódová základna nemá žádné testy, které by ji zálohovaly, nikdo se neodváží nic změnit, protože se bojí, že něco poruší.

„Wtf. Proč je tato větev kódu dokonce tam?.

Díky testům může kdokoli s jistotou říci: „Udělal jsem drastické změny, ale všechny testy stále probíhají.“ Podle definice nic nezlomil. To vede k agilnějším projektům, které se mohou vyvíjet. Možná jedním z důvodů, proč stále potřebujeme lidi, aby udržovali COBOL, je to, že testování nebylo od té doby populární: P

1
kizzx2

Pokud je kombinace rozpočtu, požadavků a týmových dovedností v kvadrantu projektového prostoru, „vzdejte se naděje všem, kdo sem vstoupíte“, pak je z velké části pravděpodobné, že projekt selže.

Možná jsou požadavky složité a nestálé, infrastruktura nestabilní, tým juniorů a s vysokou fluktuací, nebo architekt je idiot.

U projektu TDD je příznakem této hrozící poruchy to, že testy nelze psát podle plánu; zkusíte, jen abyste objevili ', že to bude trvat toto dlouhé, a my máme pouze to'.

Jiné přístupy ukáží různé příznaky, když selžou; nejčastěji dodávka systému, který nefunguje. Politika a smlouvy určí, zda je to lepší.

0
soru

Myslím, že ano, viz Test Driven Development opravdu funguje

V roce 2008 Napsali Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat a Laurie Williams příspěvek s názvem „Realizace zlepšování kvality prostřednictvím vývoje řízeného testem: výsledky a zkušenosti čtyř průmyslových týmů“ (odkaz PDF). Abstrakt:

Testem řízený vývoj (TDD) je praxe vývoje softwaru, která se sporadicky používá po celá desetiletí. S touto praxí softwarový inženýr cykluje minutu po minutě mezi zápisem testů selhání jednotky a zápisem implementačního kódu, aby tyto testy úspěšně absolvoval. Testem řízený vývoj se nedávno znovu objevil jako kritická umožňující praxe agilních metodik vývoje softwaru. Jen málo empirických důkazů však podporuje nebo vyvrací užitečnost této praxe v průmyslovém kontextu. Případové studie byly provedeny se třemi vývojovými týmy v Microsoftu a jedním v IBM, které přijaly TDD. 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% v porovnání s podobnými projekty, které nepoužívaly praxi TDD. Subjekty subjektivně zaznamenaly 15–35% prodloužení počáteční doby vývoje po přijetí TDD.

V roce 2012 Ruby on Rails) vývojové postupy předpokládají TDD. Osobně se spoléhám na nástroje, jako je rspec pro psaní testů a falešných zpráv, factory_girl pro vytváření objektů, capybara pro prohlížeč automatizace, simplecov pro pokrytí kódu a stráž pro automatizaci těchto testů.

V důsledku použití této metodiky a těchto nástrojů mám tendenci subjektivně souhlasit s Nagappanem et al ...

0
Hiltmon