Svantaggi dello sviluppo basato sui test?[Chiuso]

https://stackoverflow.com/questions/64333

09-06-2019
|

Domanda

Cosa perdo adottando un design basato sui test?

Elenca solo gli aspetti negativi;non elencare i benefici scritti in forma negativa.

Soluzione

Diversi aspetti negativi (e non sto sostenendo che non ci siano vantaggi, soprattutto quando si scrivono le basi di un progetto, alla fine si risparmierebbe molto tempo):

Grande investimento. Nel caso semplice si perde circa il 20% dell'implementazione effettiva, ma nei casi complicati si perde molto di più.
Complessità aggiuntiva. Per i casi complessi i tuoi casi di test sono più difficili da calcolare, suggerirei in casi come questo di provare a utilizzare il codice di riferimento automatico che verrà eseguito in parallelo nella versione di debug/esecuzione del test, invece del test unitario dei casi più semplici.
Impatti sulla progettazione. A volte il design non è chiaro all'inizio e si evolve man mano che procedi: questo ti costringerà a rifare il test, il che genererà una grossa perdita di tempo.Suggerirei di posticipare i test unitari in questo caso finché non avrai in mente una certa comprensione del progetto.
Ottimizzazione continua. Per le strutture dati e gli algoritmi della scatola nera i test unitari sarebbero perfetti, ma per gli algoritmi che tendono a essere modificati, ottimizzati o messi a punto, ciò può causare un grande investimento di tempo che si potrebbe sostenere non sia giustificato.Quindi usalo quando ritieni che si adatti effettivamente al sistema e non forzare il design per adattarsi a TDD.

Altri suggerimenti

Se vuoi fare un TDD "vero" (leggi:testare prima con i passaggi rosso, verde e refactoring), quindi devi anche iniziare a utilizzare mock/stub, quando vuoi testare i punti di integrazione.

Quando inizi a utilizzare i mock, dopo un po' vorrai iniziare a utilizzare Dependency Injection (DI) e un contenitore Inversion of Control (IoC).Per fare ciò è necessario utilizzare interfacce per tutto (che presentano molte insidie).

Alla fine della giornata, devi scrivere molto più codice che se lo facessi semplicemente alla "vecchia maniera".Invece di limitarsi a una classe cliente, è necessario scrivere anche un'interfaccia, una classe simulata, alcune configurazioni IoC e alcuni test.

E ricorda che anche il codice di test va mantenuto e curato.I test dovrebbero essere leggibili come tutto il resto e ci vuole tempo per scrivere un buon codice.

Molti sviluppatori non capiscono bene come eseguire tutte queste operazioni "nel modo giusto".Ma poiché tutti dicono loro che il TDD è l'unico vero modo per sviluppare software, fanno semplicemente del loro meglio.

È molto più difficile di quanto si possa pensare.Spesso i progetti realizzati con TDD finiscono con l'avere molto codice che nessuno capisce veramente.I test unitari spesso testano la cosa sbagliata, nel modo sbagliato.E nessuno è d’accordo su come dovrebbe essere un buon test, nemmeno i cosiddetti guru.

Tutti questi test rendono molto più difficile "cambiare" (al contrario del refactoring) il comportamento del tuo sistema e semplici modifiche diventano semplicemente troppo difficili e richiedono tempo.

Se leggi la letteratura TDD, ci sono sempre degli ottimi esempi, ma spesso nelle applicazioni della vita reale è necessario disporre di un'interfaccia utente e di un database.È qui che il TDD diventa davvero difficile e la maggior parte delle fonti non offre buone risposte.E se lo fanno, ciò implica sempre più astrazioni:oggetti mock, programmazione su un'interfaccia, pattern MVC/MVP ecc., che richiedono ancora molta conoscenza e...devi scrivere ancora più codice.

Perciò stai attento...se non hai un team entusiasta e almeno uno sviluppatore esperto che sappia scrivere buoni test e conosca anche alcune cose sulla buona architettura, devi davvero pensarci due volte prima di intraprendere la strada del TDD.

Quando arrivi al punto in cui hai un gran numero di test, la modifica del sistema potrebbe richiedere la riscrittura di alcuni o tutti i tuoi test, a seconda di quali sono stati invalidati dalle modifiche.Ciò potrebbe trasformare una modifica relativamente rapida in una modifica che richiede molto tempo.

Inoltre, potresti iniziare a prendere decisioni di progettazione basate più sul TDD che su principi di progettazione effettivamente validi.Mentre potresti avere una soluzione molto semplice e facile che è impossibile testare come richiede TDD, ora hai un sistema molto più complesso che in realtà è più incline agli errori.

Penso che il problema più grande per me sia l'ENORME perdita di tempo necessaria per "entrarci".Sono ancora all'inizio del mio viaggio con TDD (vedi mio blog per aggiornare le mie avventure di test se sei interessato) e ho letteralmente speso ore iniziare.

Ci vuole molto tempo per mettere il cervello in "modalità test" e scrivere "codice testabile" è un'abilità in sé.

TBH, sono rispettosamente in disaccordo I commenti di Jason Cohen sul rendere pubblici i metodi privati, non si tratta di questo. Nel mio nuovo modo di lavorare non ho reso pubblici più metodi di prima.Tuttavia, comporta modifiche all'architettura e consente di "collegare a caldo" i moduli di codice per rendere tutto il resto più semplice da testare.Dovresti non rendi le parti interne del tuo codice più accessibili per farlo.Altrimenti torniamo al punto di partenza con tutto ciò che è pubblico, dov'è l'incapsulamento in questo?

Quindi, (IMO) in poche parole:

La quantità di tempo necessaria per pensare (ad es.davvero brontolando test).
La nuova conoscenza richiesta per sapere come scrivere codice testabile.
Comprendere le modifiche architetturali necessarie per rendere il codice testabile.
Aumentare le tue abilità di "TDD-Coder" mentre cerchi di migliorare tutte le altre abilità richieste per il nostro glorioso mestiere di programmazione :)
Organizzare la base di codice per includere il codice di test senza rovinare il codice di produzione.

PS:Se desideri collegamenti a aspetti positivi, ho posto e risposto a diverse domande al riguardo, controlla il mio profilo.

Nei pochi anni in cui ho praticato il Test Driven Development, devo dire che i maggiori svantaggi sono:

Venderlo alla direzione

Il TDD è meglio farlo in coppia.Per prima cosa, è difficile resistere all'impulso di scrivere semplicemente l'implementazione quando tu SAPERE come scrivere un se altro dichiarazione.Ma una coppia ti manterrà impegnato perché tu mantieni lui impegnato.Purtroppo, molte aziende/manager non pensano che questo sia un buon uso delle risorse.Perché pagare due persone per scrivere una funzionalità, quando ho due funzionalità che devono essere realizzate contemporaneamente?

Venderlo ad altri sviluppatori

Alcune persone semplicemente non hanno la pazienza di scrivere test unitari.Alcuni sono molto orgogliosi del loro lavoro.Oppure, ad alcuni piace semplicemente vedere metodi/funzioni contorti fuoriuscire dall'estremità dello schermo.TDD non è per tutti, ma vorrei davvero che lo fosse.Renderebbe la manutenzione delle cose molto più semplice per quelle povere anime che ereditano il codice.

Mantenimento del codice di test insieme al codice di produzione

Idealmente, i tuoi test si interrompono solo quando prendi una decisione sbagliata sul codice.Cioè, pensavi che il sistema funzionasse in un modo, e si scopre che non è così.Rompere un test, o una (piccola) serie di test, questa è in realtà una buona notizia.Sai esattamente come il tuo nuovo codice influenzerà il sistema.Tuttavia, se i tuoi test sono scritti male, strettamente accoppiati o, peggio ancora, generati (tosse VS Test), quindi mantenere i tuoi test può diventare rapidamente un coro.E, dopo che un numero sufficiente di test iniziano a causare più lavoro rispetto al valore percepito che stanno creando, i test saranno la prima cosa ad essere eliminati quando i programmi vengono compressi (ad es.arriva il momento cruciale)

Scrivere test in modo da coprire tutto (copertura del codice al 100%)

Idealmente, ancora una volta, se aderisci alla metodologia, il tuo codice verrà testato al 100% per impostazione predefinita.In genere, mi ritrovo con una copertura del codice superiore al 90%.Questo di solito accade quando ho un'architettura di stile del modello e la base è testata e provo a prendere scorciatoie e a non testare le personalizzazioni del modello.Inoltre, ho scoperto che quando incontro una nuova barriera che non avevo mai incontrato in precedenza, ho una curva di apprendimento nel testarla.Ammetto di aver scritto alcune righe di codice alla vecchia maniera, ma mi piace davvero farlo al 100%.(Immagino di aver avuto risultati eccessivi a scuola, ehm skool).

Tuttavia, con ciò direi che i vantaggi di TDD superano di gran lunga gli aspetti negativi per la semplice idea che se riesci a ottenere una buona serie di test che coprano la tua applicazione ma non siano così fragili da interromperli tutti con una modifica, lo farai potrai continuare ad aggiungere nuove funzionalità il giorno 300 del tuo progetto come hai fatto il giorno 1.Questo non accade a tutti coloro che provano TDD pensando che sia una bacchetta magica per tutto il loro codice pieno di bug, e quindi pensano che non possa funzionare, punto.

Personalmente ho scoperto che con TDD scrivo codice più semplice, passo meno tempo a discutere se una particolare soluzione di codice funzionerà o meno e non ho paura di modificare qualsiasi riga di codice che non soddisfi i criteri stabiliti da Il gruppo.

Il TDD è una disciplina difficile da padroneggiare, ci lavoro da alcuni anni e continuo a imparare nuove tecniche di test.Si tratta di un enorme investimento di tempo in anticipo, ma, a lungo termine, la tua sostenibilità sarà molto maggiore che se non avessi test unitari automatizzati.Ora, se solo i miei capi potessero capirlo.

Nel tuo primo progetto TDD ci sono due grandi perdite: tempo e libertà personale

Perdi tempo perché:

La creazione di una suite completa, rifattorizzata e manutenibile di test unitari e di accettazione richiede molto tempo alla prima iterazione del progetto.Questo può essere tempo risparmiato a lungo termine, ma può anche essere tempo che non devi risparmiare.
Devi scegliere e diventare esperto in un insieme fondamentale di strumenti.Uno strumento di test unitario deve essere integrato da una sorta di framework fittizio ed entrambi devono diventare parte del tuo sistema di build automatizzato.Vuoi anche scegliere e generare metriche appropriate.

Perdi la libertà personale perché:

TDD è un modo molto disciplinato di scrivere codice che tende a scontrarsi con coloro che si trovano in alto e in basso nella scala delle competenze.Scrivere sempre il codice di produzione in un certo modo e sottoporre il proprio lavoro a una continua revisione tra pari può spaventare i tuoi peggiori e migliori sviluppatori e persino portare alla perdita di personale.
La maggior parte dei metodi Agile che incorporano il TDD richiedono che tu parli continuamente con il cliente di ciò che proponi di realizzare (in questa storia/giorno/qualunque cosa) e quali siano i compromessi.Ancora una volta questa non è la tazza di tè di tutti, sia dal lato degli sviluppatori che dei clienti.

Spero che questo ti aiuti

TDD richiede che tu pianifichi come funzioneranno le tue classi prima di scrivere il codice per superare tali test.Questo è sia un vantaggio che uno svantaggio.

Trovo difficile scrivere test nel "vuoto", prima che il codice sia stato scritto.Nella mia esperienza tendo a inciampare nei miei test ogni volta che inevitabilmente penso a qualcosa mentre scrivo le lezioni che ho dimenticato mentre scrivevo i miei test iniziali.Quindi è il momento di rifattorizzare non solo le mie lezioni, ma ANCHE i miei test.Ripeti l'operazione tre o quattro volte e può diventare frustrante.

Preferisco scrivere prima una bozza delle mie lezioni, quindi scrivere (e mantenere) una batteria di test unitari.Dopo che ho una bozza, TDD funziona bene per me.Ad esempio, se viene segnalato un bug, scriverò un test per sfruttare quel bug e quindi correggere il codice in modo che il test venga superato.

La prototipazione può essere molto difficile con TDD: quando non sei sicuro di quale strada intraprendere per raggiungere una soluzione, scrivere i test in anticipo può essere difficile (a parte quelli molto ampi).Questo può essere un dolore.

Onestamente non penso che per lo "sviluppo core" per la stragrande maggioranza dei progetti ci sia un vero svantaggio;se ne parla molto più di quanto dovrebbe essere, di solito da persone che credono che il loro codice sia abbastanza buono da non aver bisogno di test (non lo è mai) e da persone che semplicemente non possono prendersi la briga di scriverli.

Bene, e con questo allungamento, devi eseguire il debug dei tuoi test.Inoltre, c'è un certo costo in termini di tempo per scrivere i test, anche se la maggior parte delle persone concorda sul fatto che si tratta di un investimento iniziale che viene ripagato nel corso della vita dell'applicazione sia in termini di tempo risparmiato nel debugging che in stabilità.

Il problema più grande che ho avuto personalmente, però, è stato acquisire la disciplina necessaria per scrivere effettivamente i test.In una squadra, soprattutto in una squadra consolidata, può essere difficile convincerli che vale la pena dedicare il tempo.

Se i tuoi test non sono molto approfonditi potresti cadere nel falso senso di "tutto funziona" solo perché i test vengono superati.Teoricamente se i test passano, il codice funziona;ma se potessimo scrivere il codice perfettamente la prima volta non avremmo bisogno di test.La morale qui è assicurarsi di fare da soli un controllo di integrità prima di chiamare qualcosa di completo, non fare affidamento solo sui test.

In tale nota, se il tuo controllo di integrità trova qualcosa che non è stato testato, assicurati di tornare indietro e scrivere un test per quello.

Lo svantaggio di TDD è che di solito è strettamente associato alla metodologia "Agile", che colloca NO L'importanza della documentazione di un sistema, piuttosto la comprensione del motivo per cui un test "dovrebbe" restituire un valore specifico piuttosto che un altro risiede solo nella testa dello sviluppatore.

Non appena lo sviluppatore lascia o dimentica il motivo per cui il test restituisce un valore specifico e non un altro, sei fregato.TDD va bene SE è adeguatamente documentato e circondato da caratteri leggibili dall'uomo (ad es.manager dai capelli a punta) documentazione a cui si potrà fare riferimento tra 5 anni, quando il mondo cambierà e anche la tua app avrà bisogno di farlo.

Quando parlo di documentazione, non si tratta di una descrizione in codice, ma di scritti ufficiali che esistono esternamente all'applicazione, come casi d'uso e informazioni di base a cui possono fare riferimento manager, avvocati e il povero idiota che deve aggiornare il tuo codice nel 2011.

Ho riscontrato diverse situazioni in cui il TDD mi fa impazzire.Per citarne alcuni:

Manutenibilità del caso di test:

Se lavori in una grande azienda, è probabile che non sia necessario scrivere tu stesso i casi di test o almeno la maggior parte di essi venga scritta da qualcun altro quando entri in azienda.Le funzionalità di un'applicazione cambiano di volta in volta e se non disponi di un sistema, come HP Quality Center, per tenerne traccia, diventerai matto in pochissimo tempo.

Ciò significa anche che i nuovi membri del team impiegheranno una discreta quantità di tempo per capire cosa sta succedendo con i casi di test.A sua volta, ciò può tradursi in una maggiore necessità di denaro.
Complessità dell'automazione dei test:

Se automatizzi alcuni o tutti i casi di test in script di test eseguibili dalla macchina, dovrai assicurarti che questi script di test siano sincronizzati con i corrispondenti casi di test manuali e in linea con le modifiche dell'applicazione.

Inoltre, dedicherai del tempo al debug dei codici che ti aiutano a individuare i bug.A mio parere, la maggior parte di questi bug deriva dall'incapacità del team di test di riflettere le modifiche dell'applicazione nello script di test di automazione.I cambiamenti nella logica aziendale, nella GUI e in altri elementi interni possono far sì che i tuoi script smettano di funzionare o funzionino in modo inaffidabile.A volte i cambiamenti sono molto sottili e difficili da rilevare.Una volta tutti i miei script segnalavano un errore perché basavano il calcolo sulle informazioni della tabella 1 mentre la tabella 1 era ora la tabella 2 (perché qualcuno ha scambiato il nome degli oggetti della tabella nel codice dell'applicazione).

Il problema più grande sono le persone che non sanno come scrivere unit test adeguati.Scrivono test che dipendono l'uno dall'altro (e funzionano benissimo con Ant, ma poi all'improvviso falliscono quando li eseguo da Eclipse, solo perché vengono eseguiti in ordine diverso).Scrivono test che non testano nulla in particolare: eseguono semplicemente il debug del codice, controllano il risultato e lo modificano in test, chiamandolo "test1".Ampliano la portata delle classi e dei metodi, proprio perché sarà più semplice scrivere test unitari per loro.Il codice degli unit test è terribile, con tutti i classici problemi di programmazione (accoppiamento pesante, metodi lunghi 500 righe, valori codificati, duplicazione del codice) ed è un inferno da mantenere.Per qualche strana ragione le persone trattano i test unitari come qualcosa di inferiore al codice "reale" e non si preoccupano affatto della loro qualità.:-(

Perdi molto tempo speso a scrivere i test.Naturalmente, questo potrebbe essere salvato entro la fine del progetto individuando i bug più velocemente.

Perdi la possibilità di dire che hai "finito" prima di testare tutto il tuo codice.

Perdi la capacità di scrivere centinaia o migliaia di righe di codice prima di eseguirlo.

Perdi l'opportunità di apprendere attraverso il debug.

Perderai la flessibilità di spedire codici di cui non sei sicuro.

Perdi la libertà di accoppiare strettamente i tuoi moduli.

Perdi la possibilità di saltare la scrittura della documentazione di progettazione di basso livello.

Perdi la stabilità che deriva dal codice che tutti hanno paura di cambiare.

Perderai il titolo di "hacker".

Lo svantaggio più grande è che se vuoi davvero eseguire correttamente il TDD dovrai fallire molto prima di avere successo.Dato il numero di società di software che lavorano (dollaro per KLOC), alla fine verrai licenziato.Anche se il tuo codice è più veloce, più pulito, più facile da mantenere e contiene meno bug.

Se lavori in un'azienda che ti paga in base ai KLOC (o ai requisiti implementati, anche se non testati), stai lontano dal TDD (o dalle revisioni del codice, dalla programmazione in coppia, dall'integrazione continua, ecc.eccetera.eccetera.).

Condivido la risposta sul tempo di sviluppo iniziale.Perdi anche la capacità di lavorare comodamente senza la sicurezza dei test.Sono stato anche descritto come un pazzo del TDD, quindi potresti perdere qualche amico ;)

Riconcentrarsi su requisiti difficili e imprevisti è la costante rovina del programmatore.Lo sviluppo basato sui test ti costringe a concentrarti sui requisiti banali già noti e limita il tuo sviluppo a ciò che è già stato immaginato.

Pensaci, è probabile che finirai per progettare casi di test specifici, quindi non diventerai creativo e inizierai a pensare "sarebbe bello se l'utente potesse fare X, Y e Z".Pertanto, quando l'utente inizia ad essere entusiasta dei potenziali interessanti requisiti X, Y e Z, il progetto potrebbe essere troppo rigidamente focalizzato su casi di test già specificati e sarà difficile da adattare.

Questa, ovviamente, è un’arma a doppio taglio.Se passi tutto il tuo tempo a progettare ogni X, Y e Z concepibile e immaginabile che un utente possa desiderare, inevitabilmente non completerai mai nulla.Se completi qualcosa, sarà impossibile per chiunque (incluso te stesso) avere idea di cosa stai facendo nel tuo codice/design.

È percepito come più lento.A lungo termine questo non è vero in termini di dolore che ti farà risparmiare lungo la strada, ma finirai per scrivere più codice, quindi probabilmente stai dedicando tempo a "testare, non codificare".È un argomento errato, ma l'hai chiesto!

Può essere difficile e dispendioso in termini di tempo scrivere test per dati "casuali" come feed XML e database (non così difficile).Ultimamente ho passato un po' di tempo a lavorare con i feed di dati meteorologici.È abbastanza confuso scrivere test per questo, almeno perché non ho molta esperienza con TDD.

Perderai classi numerose con molteplici responsabilità.Probabilmente perderai anche metodi di grandi dimensioni con molteplici responsabilità.Potresti perdere parte della capacità di eseguire il refactoring, ma perderai anche parte della necessità di eseguire il refactoring.

Jason Cohen ha detto qualcosa del tipo:TDD richiede una determinata organizzazione per il tuo codice.Questo potrebbe essere architettonicamente sbagliato;ad esempio, poiché i metodi privati non possono essere chiamati all'esterno di una classe, è necessario rendere i metodi non privati per renderli testabili.

Dico che questo indica un'astrazione mancata: se il codice privato ha davvero bisogno di essere testato, probabilmente dovrebbe trovarsi in una classe separata.

Dave Mann

Devi scrivere le applicazioni in un modo diverso:uno che li rende testabili.Saresti sorpreso di quanto sia difficile all'inizio.

Alcune persone trovano troppo difficile pensare a ciò che scriveranno prima di scriverlo.Anche concetti come la derisione possono essere difficili per alcuni.Il TDD nelle app legacy può essere molto difficile se non sono state progettate per i test.Anche il TDD attorno a framework che non sono compatibili con TDD può essere una lotta.

Il TDD è un'abilità per cui gli sviluppatori junior potrebbero avere difficoltà all'inizio (principalmente perché non è stato loro insegnato a lavorare in questo modo).

Nel complesso, tuttavia, i contro si risolvono man mano che le persone diventano abili e si finisce per eliminare il codice "puzzolente" e avere un sistema più stabile.

Ci vuole un po' di tempo per entrarci e un po' di tempo per iniziare a farlo in un progetto, ma...Mi pento sempre di non aver adottato un approccio Test Driven quando trovo bug stupidi che un test automatizzato avrebbe potuto rilevare molto velocemente.Inoltre, TDD migliora la qualità del codice.

I test unitari richiedono più codice da scrivere, quindi un costo iniziale di sviluppo più elevato
è più codice da mantenere
ulteriore apprendimento richiesto

Buone risposte a tutti.Vorrei aggiungere alcuni modi per evitare il lato oscuro del TDD:

Ho scritto app per eseguire il proprio autotest randomizzato.Il problema con la scrittura di test specifici è che anche se ne scrivi molti, coprono solo i casi a cui pensi.I generatori di test casuali trovano problemi a cui non avevi pensato.
L'intero concetto di numerosi test unitari implica la presenza di componenti che possono entrare in stati non validi, come strutture di dati complesse.Se stai lontano da strutture dati complesse c'è molto meno da testare.
Nella misura in cui la tua applicazione lo consente, sii timido con un design che si basa sul corretto ordine di notifiche, eventi ed effetti collaterali.Questi possono facilmente cadere o strapazzarsi, quindi necessitano di molti test.

TDD richiede una determinata organizzazione per il tuo codice.Questo potrebbe essere inefficiente o difficile da leggere.O anche architettonicamente sbagliato;per esempio, da allora private i metodi non possono essere chiamati al di fuori di una classe, devi rendere i metodi non privati per renderli testabili, il che è semplicemente sbagliato.

Quando il codice cambia, devi cambiare anche i test.Con il refactoring questo può essere un sacco di lavoro extra.

Vorrei aggiungere che se applichi i principi BDD a un progetto TDD, puoi alleviare alcuni dei principali inconvenienti elencati qui (confusione, incomprensioni, ecc.).Se non hai familiarità con BDD, dovresti leggere l'introduzione di Dan North.Ha ideato il concetto in risposta ad alcuni dei problemi sorti dall'applicazione del TDD sul posto di lavoro.È possibile trovare l'introduzione di Dan a BDD Qui.

Fornisco questo suggerimento solo perché BDD affronta alcuni di questi aspetti negativi e agisce come un gap-stop.Ti consigliamo di considerare questo aspetto quando raccogli il tuo feedback.

Devi assicurarti che i tuoi test siano sempre aggiornati, nel momento in cui inizi a ignorare i semafori rossi è il momento in cui i test diventano privi di significato.

Devi anche assicurarti che i test siano completi, altrimenti nel momento in cui appare un grosso bug, il tipo di gestione noioso che hai finalmente convinto a lasciarti dedicare tempo a scrivere più codice si lamenterà.

La persona che ha insegnato al mio team lo sviluppo agile non credeva nella pianificazione, tu scrivevi solo per il più piccolo requisito.

Il suo motto era refactoring, refactoring, refactoring.Sono arrivato a capire che refactoring significava "non pianificare in anticipo".

Il tempo di sviluppo aumenta:Ogni metodo necessita di test e se hai un'applicazione di grandi dimensioni con dipendenze devi preparare e pulire i dati per i test.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow