TDD / Test troppo sovraccarico / oneri di manutenzione?

24

Quindi l'hai sentito molte volte da coloro che non comprendono veramente i valori dei test. Per iniziare, sono un seguace di Agile and Testing ...

Recentemente ho avuto una discussione sull'esecuzione di TDD su una riscrittura di un prodotto in cui il team attuale non pratica i test unitari a nessun livello e probabilmente non ha mai sentito parlare della tecnica di iniezione di dipendenza o dei modelli di test / design ecc. t anche arrivare a pulire il codice).

Ora, sono pienamente responsabile per la riscrittura di questo prodotto e mi è stato detto che il tentativo di farlo nel modo di TDD, lo renderà semplicemente un incubo di manutenzione e impossibile per la squadra mantenere. Inoltre, poiché si tratta di un'applicazione front-end (non basata sul Web), l'aggiunta di test è inutile, poiché il business drive cambia (con cambiamenti significano miglioramenti, ovviamente), i test diventeranno obsoleti, altri sviluppatori che si avvicinano a il progetto in futuro non li manterrà e diventerà più un fardello per loro da sistemare ecc.

Posso capire che il TDD in una squadra che al momento non detiene alcuna esperienza di test non suona bene, ma la mia argomentazione in questo caso è che posso insegnare la mia pratica a chi mi circonda, ma ancora di più, so che TDD crea il software BETTER. Anche se dovessi produrre il software usando TDD e buttare via tutti i test per affidarlo a un team di manutenzione, sarebbe sicuramente un approccio migliore rispetto a non usare il TDD fin dall'inizio?

Sono stato abbattuto come ho detto di fare TDD sulla maggior parte dei progetti per una squadra che non ne ha mai sentito parlare. Il pensiero di "interfacce" e di costruttori DI dall'aspetto strano li spaventa ...

Qualcuno può aiutarmi per favore in quella che normalmente è una conversazione molto breve di provare a vendere TDD e il mio approccio alle persone? Di solito ho una finestra di discussione molto breve prima di cadere in ginocchio alla compagnia / squadra.

    
posta Martin Blore 31.01.2011 - 22:48
fonte

7 risposte

36

attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain.

Non puoi vincere quell'argomento. Lo stanno inventando. Purtroppo, non hai nemmeno fatti reali. Qualsiasi esempio fornito può essere contestato.

L'unico modo per chiarire questo punto è quello di avere un codice che è più economico da mantenere.

Furthermore, as it's a front-end application (not web-based), adding tests is pointless,

Tutti lo dicono. Potrebbe anche essere parzialmente vero. Se l'applicazione è ragionevolmente ben progettata, il front-end fa molto poco.

Se l'applicazione è mal progettata, tuttavia, il front-end fa troppo ed è difficile da testare. Questo è un problema di progettazione, non un problema di test.

as the business drive changes (by changes they mean improvements of course), the tests will become out of date, other developers who come on to the project in the future will not maintain them and become more of a burden for them to fix etc.

Questo è lo stesso argomento di prima.

Non puoi vincere l'argomento. Quindi non discutere.

"Sono pienamente responsabile della riscrittura di questo prodotto"

In tal caso,

  1. Aggiungi test comunque. Ma aggiungi i test man mano che procedi, in modo incrementale. Non passare molto tempo a scrivere i test per primi. Converti un po '. Prova un po ' Converti un po 'di più. Prova ancora un po '.

  2. Utilizza questi test finché qualcuno non capisce che il test funziona e chiede perché le cose vanno così bene.

Ho avuto lo stesso argomento su una riscrittura (da C ++ a Java) e ho semplicemente usato i test anche se mi hanno detto di non farlo.

Mi stavo sviluppando molto rapidamente. Ho chiesto esempi concreti di risultati corretti, che hanno inviato in fogli di calcolo. Ho trasformato i fogli di calcolo in unittest.TestCase (senza dirlo a nessuno) e li usa per testare.

Durante i test di accettazione degli utenti - e sono stati trovati errori - ho appena chiesto i fogli di calcolo con gli esempi da rivedere, correggere e ampliare per coprire i problemi riscontrati durante il test di accettazione. Ho trasformato i fogli di calcolo corretti in unittest.TestCase (senza dirlo) e li utilizza per testare.

Nessuno ha bisogno di sapere in dettaglio perché hai successo.

Basta avere successo.

    
risposta data 31.01.2011 - 23:14
fonte
5

Puoi solo convincere queste persone (se non del tutto) dal punto di vista pratico, dimostrando il valore del TDD nella vita reale. Per esempio. prendendo come esempio un bug recente e mostrando come costruire un unit test che si assicura al 100% che questo bug non possa mai apparire di nuovo. E poi, naturalmente, scrivi una dozzina di altri test unitari per evitare che l'intera classe di bug simili si mostri (e chissà, magari sulla strada anche scoprendo alcuni altri bug in sospeso nel codice).

Se questo non funziona a breve termine, è necessario lavorare su questo più a lungo, semplicemente facendo TDD e scrivendo i test di unità diligentemente sulle proprie attività. Quindi compilare alcune semplici statistiche dopo circa un anno o giù di lì (se è possibile nel tuo ambiente) per confrontare le percentuali di errori nel codice / attività realizzate da diversi sviluppatori (anonimizzati per evitare di alienare i tuoi compagni di squadra). Se riesci a far notare che ci sono stati molti meno errori nel tuo codice rispetto ad altri ', potresti avere un punto di forza da vendere sia al management che ai colleghi sviluppatori.

    
risposta data 31.01.2011 - 22:54
fonte
3

Devi essere pratico su queste cose, TDD è una cosa carina da avere in teoria, ma a meno che tu non stia aggiornando i test per tutto ciò che viene aggiunto, non ha molto senso - nessuno vuole eseguire un test che riporta il codice rotto quando è il test che non è stato aggiornato! Di conseguenza, può essere troppo costoso per farli - non sarai l'unico sviluppatore che lavora su quel codice.

Il cliente ha un team di test .. beh, non c'è alcun problema nello spostare il carico di test dallo sviluppatore ai tester - questo è quello che sono lì per dopo, e se trovano bug attraverso i loro test (forse hanno un sacco di strumenti di test automatici) quindi non ha molto senso scrivere test unitari al tuo livello. Ci vorrà un po 'più di tempo per trovare i bug, ma troveranno quei fastidiosi bug di "integrazione" che i tuoi test non avrebbero esercitato.

È probabile che questo è il motivo per cui non si preoccupano dei test unitari.

Infine, TDD è una novità, quando ero un ragazzo non abbiamo mai avuto test e abbiamo scritto codice funzionante. Il test delle unità rende alcune persone calde e sfocate, ma non è assolutamente necessario per il codice corretto.

PS. Vedo un'altra delle tue domande in cui critichi gli strati di astrazione, e qui critichi la mancanza di costruttori DI! Pensaci:)

    
risposta data 14.04.2011 - 00:22
fonte
2

Poiché tutto cambia così rapidamente mentre lo metti, spiega loro che sarà usato per i test di regressione. Che salverà un sacco di grattacapi quando vengono introdotti nuovi bug perché qualcuno ha rotto una riga di codice che è stata scritta 10 anni fa per risolvere un problema che si verifica 1 su ogni 10.000.000 esecuzioni di una funzione specifica che viene chiamata solo se l'orologio di sistema è acceso il client ha una differenza superiore a 3 minuti rispetto all'orologio del sistema del server. Basta chiedere loro quanti clienti possono permettersi di perdere a causa del software buggy.

    
risposta data 31.01.2011 - 22:53
fonte
2

Fai notare che trovare un bug durante lo sviluppo costa X, durante il test 10X e dopo l'implementazione 100X. Verifica se almeno ti permetteranno di condurre un test pilota in cui implementerai TDD in un modulo specifico, quindi prosegui con il confronto con altri moduli man mano che vengono sviluppati, testati, distribuiti e supportati. Dati dati adeguati, dovresti essere in grado di dimostrare quanto sia stato impiegato meno sforzo per produrre codice nel modulo TDD. Buona fortuna.

    
risposta data 01.02.2011 - 04:33
fonte
2

Sì, il mantenimento dei test è un onere. Aggiornandoli, aggiornando i dati di test: tutto questo fa schifo.

L'alternativa: testare manualmente le cose, rifare bug che regrediscono, non essere in grado di dire in pochi secondi che il tuo codice funziona, costa molto di più.

    
risposta data 01.02.2011 - 19:20
fonte
2

Il test è oneroso, ma è un buon fardello da trasportare. È meglio fare un po 'di lavoro in anticipo, risparmiando una buona quantità di tempo in caso di problemi di produzione o durante la migrazione. Voglio sempre fare dei test anche se è un piccolo peso, ma voglio portare questo onere.

    
risposta data 01.02.2011 - 19:30
fonte

Leggi altre domande sui tag