it-swarm-eu.dev

Jaké jsou nevýhody programování prvního testu?

Dnes je to všechno vztek. „Každý“ to doporučuje. To samo o sobě mě dělá podezřelým.

Jaké jsou některé nevýhody, které jste zjistili při provádění prvního testu (na základě testu)? Hledám osobní zkušenosti od zkušených praktiků - na internetu si mohu přečíst hypotetické úvahy stovky rádoby jinde.

Ptám se ne proto, že se snažím nenávidět TDD, ale protože je mou prací zlepšovat proces vývoje softwaru a čím více se můžeme dozvědět o problémech, s nimiž se lidé setkávají, tím větší šanci máme na zlepšení procesu.

48
Alex Feinman

Existuje poměrně málo, ale výhody daleko převažují nad nevýhodami.

Je zde strmá křivka učení.

Zdá se, že mnoho vývojářů očekává, že mohou být efektivní s testovacím prvním programováním hned od prvního dne. Naneštěstí to vyžaduje hodně času, abychom získali zkušenosti a program stejnou rychlostí jako dříve. Nemůžete to obejít.

Abych byl konkrétnější, je velmi snadné se mýlit. Můžete velmi snadno (s velmi dobrými úmysly) nakonec napsat celou řadu testů, které je obtížné udržovat nebo testovat špatné věci. Je obtížné zde uvést příklady - tyto problémy jednoduše vyžadují řešení. Musíte mít dobrý pocit oddělovat obavy a navrhovat testovatelnost. Moje nejlepší rada by zde byla udělat párové programování s někým, kdo zná TDD opravdu dobře.

Děláte více kódování dopředu.

Test-first znamená, že nemůžete přeskočit testy (což je dobré) a znamená, že dopředu napíšete více kódu. To znamená více času. Opět se nemůžete obejít. Dostanete odměnu za kód, který je snadnější udržovat, rozšiřovat a obecně méně chyb, ale vyžaduje to čas.

Může to být těžký prodej manažerům.

Softwaroví manažeři se obecně zabývají pouze časovými osami. Pokud přepnete na programování s prvním testem a najednou budete potřebovat 2 týdny na dokončení funkce namísto jednoho, nebude se to líbit. Toto je rozhodně bitva, kterou stojí za to bojovat, a mnoho manažerů je dostatečně osvíceno, aby to bylo možné, ale může to být těžký prodej.

Může to být těžký prodej ostatním vývojářům.

Protože existuje strmá křivka učení, ne všichni vývojáři mají rádi programování jako první. Ve skutečnosti bych hádal, že většina vývojářů se to zpočátku nelíbí. Můžete dělat věci, jako je párové programování, které jim pomohou dostat se na rychlost, ale může to být těžký prodej.

Nakonec výhody převažují nad nevýhodami, ale nepomáhá, pokud tyto nevýhody prostě ignorujete. Vědět, s čím se zabýváte hned od začátku, vám pomůže vyjednat některé, ne-li všechny, nevýhody.

41
Jaco Pretorius

Test-first předpokládá, že píšete kód, který je:

  • testovatelné jednotkovým testovacím způsobem
  • že to, co vyvíjíte, má zřejmý přístup a nebude vyžadovat rozsáhlé prototypování ani experimentování
  • že nebudete muset příliš silně refaktorovat nebo že máte čas opakovaně přepisovat stovky či tisíce testovacích případů
  • nic není zapečetěno
  • všechno je modulární
  • všechno je injektovatelné nebo zesměšnitelné
  • že vaše organizace přikládá dostatečně nízkou hodnotu nízkým defektům, aby ospravedlnila zdrojový dřez
  • že je něco prospěšného testovat na úrovni jednotkových testů

Pokud váš projekt tyto požadavky nesplňuje, budete mít potíže. Propagátoři TDD na to nemají žádné dobré odpovědi, které by naznačovaly, že svůj produkt přepracováte tak, aby lépe spadal do těchto linií. Existují situace, kdy je to nemožné nebo nežádoucí.

V praxi se mi také může stát obrovský problém s lidmi, kteří si myslí, že první testy skutečně dokáží něco o správné funkci programu. V mnoha případech to není pravda, ale i v případech, kdy je to pravda, není ani zdaleka úplný obraz správnosti. Lidé vidí stovky úspěšných testů a předpokládají, že je bezpečné testovat méně, protože před TDD provedli jen několik stovek testovacích případů. Podle mých zkušeností TDD znamená, že musíte mít ještě více integračních testů, protože vývojáři budou mít také falešnou bezpečnost a bolest při změně všech testů, aby mohli udělat velký redaktor, může vést vývojáře k tomu, aby dělali zajímavou práci.

Příklady:

Můj osobní nejlepší příklad je při psaní bezpečnostního kódu pro asp.net. Pokud jsou určeny ke spuštění v nepřátelském prostředí ze strojové konfigurace, jsou vyznamenáni, podepsáni a zapečetěni, a protože běží proti IIS božským objektům), je velmi obtížné se vysmívat přidejte některá omezení týkající se výkonu a využití paměti a velmi rychle ztratíte flexibilitu při používání zástupných objektů ve zbývajících oblastech.

Jakýkoli typ mikroprocesoru nebo jiný kód prostředí s nízkými zdroji nemusí být možné skutečně udělat OO, protože abstrakce nejsou optimalizovány a máte nízké limity zdrojů. Totéž lze říci pro vysoce výkonné rutiny v mnoha případech.

36
Bill

Největší nevýhoda, kterou jsem viděl, není u samotného TDD, ale u praktiků. Oni berou dogmatický a zealot přístup kde všechno musí být testováno . Někdy (mnohokrát to je) to není nutné. Také to nemusí být praktické (.ie. Zavedení organizace do TDD.)

Dobrý inženýr najde kompromisy a použije správnou rovnováhu, kdy/kde/jak použít test-first. Také pokud zjistíte, že neustále trávíte mnohem více času vývojem testů namísto skutečného kódu (faktorem 2-3 nebo více), máte potíže.

Jinými slovy, buďte pragmatičtí a rozumní s TDD (nebo s čímkoli ve vývoji softwaru v této věci).

26
luis.espinal

Začal jsem dělat TDD začátkem srpna 2009 a přesvědčil jsem celou svou společnost, aby na ni přešla v září/říjnu 2009. V současné době je celý tým dev úplně převeden a odevzdání nevyzkoušeného kódu repo je považováno za špatnou věc a hodeno. Fungovalo to pro nás skvěle a nedokážu si představit přechod zpět na kódování kovboje.

Existují však dva problémy, které jsou celkem patrné.

Testovací sada musí být zachována

Když to myslíš TDD vážně, skončíš psaní partií testů. Kromě toho je třeba nějaký čas a zkušenosti, než si uvědomíme, jaká je správnost granularity testů (přehánění je téměř stejně špatné jako přehlížení). Tyto testy jsou také kód a jsou citlivé na bitrot. To znamená, že je musíte udržovat jako všechno ostatní: aktualizujte jej, když upgradujete knihovny, na nichž závisí, refaktorský čas od času ... Když provedete velké změny v kódu, spousta testů najednou zastará nebo dokonce špatně. Pokud budete mít štěstí, můžete je jednoduše smazat, ale mnohokrát skončíte extrahováním užitečných bitů a jejich přizpůsobením nové architektuře.

Testování úniků čas od čas

Používáme Django, který má docela skvělý testovací rámec. Někdy však vytváří předpoklady, které jsou mírně v rozporu s realitou. Například některé middleware mohou testy přerušit. Nebo některé testy vycházejí z mezipaměti backendu. Také, pokud používáte „skutečný“ db (nikoli SQLite3), bude příprava db na testy zabrat spoustu času. Jistě, můžete (a měli byste) použít SQLite3 a db v paměti pro testy prováděné lokálně, ale nějaký kód se bude chovat jinak v závislosti na použité databázi. Nastavení serveru pro kontinuální integraci, který běží v realistickém nastavení, je nezbytné.

(Někteří lidé vám řeknou, že byste měli zesměšňovat všechny věci, jako je databáze, nebo vaše testy nejsou „čisté“, ale to je jen mluvení ideologie. Pokud v kódu zesměšňování uděláte chyby (a věříte mi, budete), váš testsuite bude bezcenné.)

To vše říká, že problémy, které jsem popsal, začínají být patrné pouze tehdy, když jste s TDD docela pokročilí ... Když právě začínáte s TDD (nebo pracujete na menších projektech), test refactoring nebude problém.

6
Ryszard Szopa

Pro mě je tu nějaký hluboký psychologický problém s testy, kdykoli se je pokusím aplikovat extenzivně, jako v TDD: pokud jsou tam, kóduji nedbale, protože věřím, že testy zachytí nějaké problémy. Ale pokud neexistují žádné testy, které by poskytly bezpečnostní síť, kóduji pečlivě a výsledek je vždy lepší než u testů.

Možná jsem to jen já. Ale někde jsem také četl, že auta se všemi druhy bezpečnostních zvonků a píšťalek mají tendenci více padat (protože řidiči vědí, že jsou k dispozici bezpečnostní prvky), takže je to možná něco, co by se mělo uznat; TDD může být nekompatibilní s některými jednotlivci.

4
Joonas Pulakka

Jedna situace, ve které se test-first opravdu dostane do cesty, je, když chci rychle vyzkoušet nějaký nápad a zjistit, zda to může fungovat, než napíšu správnou implementaci.

Můj přístup je obvykle:

  1. Implementujte něco, co běží (důkaz konceptu).
  2. Pokud to funguje, konsolidujte přidáním testů, vylepšením designu, refaktoringem.

Někdy se nedostanu ke kroku 2.

V tomto případě se ukázalo, že používání TDD má pro mě více nevýhod než výhod:

  • Psaní testů během implementace důkazu konceptu mě jen zpomaluje a přerušuje tok myšlenek: Chci pochopit nápad a nechci ztrácet čas testováním podrobností své první hrubé implementace.
  • Může trvat déle, než zjistím, zda má myšlenka něco stojí nebo ne.
  • Pokud se ukáže, že tento nápad byl k ničemu, musím zahodit jak můj kód, tak pěkně napsané testy jednotek.

Takže, když musím prozkoumat nějaké nové nápady, nepoužívám TDD a zavádím jednotkové testy, až budu mít pocit, že se nový kód někde dostává.

2
Giorgio

Nevýhody nebo náklady na TDD

Poznámka: Existuje celá řada různých druhů TDD. Bez ohledu na jednotku, BDD, ATDD nebo jiné varianty zůstává mnoho problémů

Nežádoucí účinky

Ať už se jedná o zesměšňování, příslušenství nebo funkční testy, závislosti na vnějších stavech nebo systémech jsou často zdrojem nejkomplikovanějších testů, nejasností v tom, jak testovat, a největším rizikem, že se to pokazí. Několik problémů, které jsem viděl:

  • Zesměšňovat: zapomenout na vynucení pořadí volání
  • Vysmívat se: zesměšňovat neodpovídá skutečnému hovoru nebo odpovědi
  • Řešení: test se spoléhá na nerealistická data a maskuje další problémy
  • Svítidlo: vyzkoušejte nemožný stav ve výrobě
  • Funkční: falešné přestávky v sestavení kvůli dočasnému nedostupnosti závislého systému
  • Funkční: rychlost testu je velmi pomalá

Budete muset změnit svůj přístup k kódování, pro některé to bude drastická změna.

Různí lidé kódují divoce různými způsoby. V TDD musíte začít testem, který prokazuje specifické chování, a poté implementovat, aby test prošel. Viděl jsem a byl programátor, jehož programování nevedlo k TDD. Trvalo mi asi 2 měsíce, když jsem si zpočátku začal zvykat na změnu přístupu.

Chápe to čas, abychom pochopili, co vás zajímá testování a co vás nezajímá testování.

Každý tým by měl učinit jednoznačné rozhodnutí o tom, kde chce nakreslit čáru při testování. Jaké věci si cení, že chtějí testovat a co ne. Je to často bolestivý proces, který se učí, jak psát dobré testy, a co vás vlastně testování zajímá. Mezitím bude kód i nadále ve stavu toku, dokud nedojde ke shodě jak ve stylu, tak v přístupu.

Specifický test jednotky: velké refaktory

Velký nebo základní refaktoror významné kódové základny s desítkami tisíc jednotkových testů bude generovat obrovské náklady za účelem aktualizace všech testů. To se často projeví v protikladu proti tomu, aby se činil refaktor, i když je to správná věc jednoduše proto, že náklady spojené s jeho provedením.

1
dietbuddha

Moje analogie jsou překážky na Scalextric trati. Pokud je nasadíte, budete mnohem méně opatrní.

Lidé také dostanou o svých testech trochu prostoru kadetsky - protože fungují dobře, věří, že kód je plně testován, zatímco je to pouze začátek procesu testování.

Podle mého názoru je TDD odrazovým můstkem k BDD. Řada testů, které běží, nepomáhá vývojářům podpory, aniž by věděli, co testy dělají. U BDD je výstup testu v angličtině, který dokumentuje testování, a tím zvyšuje porozumění systému.

0
Robbie Dee