TDD / Verifica troppo un sovraccarico / onere di manutenzione?

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

Recentemente ho avuto una discussione sull'esecuzione di TDD su una riscrittura del prodotto in cui il team attuale non pratica test di unità a nessun livello e probabilmente non ho mai sentito parlare della tecnica di iniezione di dipendenza o dei modelli di test / progettazione ecc. (Non avremo nemmeno per pulire il codice).

Ora, sono pienamente responsabile della riscrittura di questo prodotto e mi viene detto che tentare alla maniera di TDD, lo renderà semplicemente un incubo di manutenzione e impossibile da mantenere per il team. Inoltre, poiché si tratta di un'applicazione front-end (non basata sul web), l'aggiunta di test è inutile, poiché il business guida cambia (con cambiamenti significano ovviamente miglioramenti), i test diventeranno obsoleti, altri sviluppatori che arrivano a il progetto in futuro non li manterrà e diventerà più un peso per loro da riparare, ecc.

Posso capire che TDD in un team che attualmente non ha alcuna esperienza di test non suona bene, ma la mia argomentazione in questo caso è che posso insegnare la mia pratica a coloro che mi circondano, ma inoltre so che TDD rende MEGLIO Software. Anche se dovessi produrre il software utilizzando TDD e buttare via tutti i test per consegnarlo a un team di manutenzione, sarebbe sicuramente un approccio migliore rispetto al non utilizzare TDD dall'inizio?

Sono stato abbattuto come ho già detto facendo TDD sulla maggior parte dei progetti per un team 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 breve conversazione sul tentativo di vendere TDD e il mio approccio alle persone? Di solito ho una breve discussione prima di cadere in ginocchio con la compagnia / squadra.

tentare alla maniera di TDD, lo renderà semplicemente un incubo per la manutenzione e impossibile da mantenere per il team.

Non puoi vincere questa discussione. Lo stanno inventando. Purtroppo, non hai fatti reali, neanche. Qualsiasi esempio fornito può essere contestato.

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

Inoltre, poiché si tratta di un'applicazione front-end (non basata sul Web), aggiungere test è inutile,

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

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

man mano che il business guida cambia (per cambiamento significano ovviamente miglioramenti), i test diventeranno obsoleti, altri sviluppatori che accederanno al progetto in futuro non li manterranno e diventeranno più un peso per loro da riparare ecc.

Questo è lo stesso argomento di cui sopra.

Non puoi vincere l'argomento. Quindi non discutere.

"Sono pienamente responsabile della riscrittura di questo prodotto"

In quel caso,

1. Aggiungi comunque dei test. Ma aggiungi i test man mano che procedi, in modo incrementale. Non perdere molto tempo prima che i test vengano scritti. Converti un po '. Prova un po '. Converti un po 'di più. Prova ancora un po '.

2. Usa questi test fino a quando qualcuno non capisce che i test funzionano e chiede perché le cose vadano 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) e li utilizzo per testarli.

Durante i test di accettazione dell'utente - e sono stati rilevati errori - ho appena chiesto che i fogli di calcolo con gli esempi fossero rivisti, corretti ed espansi per coprire i problemi riscontrati durante il test di accettazione. Ho trasformato i fogli di calcolo corretti in unittest.TestCase (senza dirlo) e li uso per testare.

Nessuno deve sapere in dettaglio perché hai successo.

Basta avere successo.

Puoi convincere queste persone (se non del tutto) dal punto di vista pratico, dimostrando il valore del TDD nella vita reale. Ad esempio prendendo alcuni bug recenti come esempio e mostrando come costruire un test unit che assicuri al 100% che questo bug potrebbe non comparire mai più. E poi ovviamente scrivere una dozzina di test unitari per impedire che appaia l'intera classe di bug simili (e chissà, forse sulla strada anche scoprire alcuni altri bug dormienti nel codice).

Se questo non funziona a breve termine, è necessario lavorarci più a lungo, semplicemente facendo TDD e scrivendo diligentemente test unitari sui propri compiti. Quindi compilare alcune semplici statistiche dopo circa sei mesi (se è possibile nel proprio ambiente) per confrontare le percentuali di bug nel codice / attività svolte da diversi sviluppatori (anonimizzate per impedire l'alienazione dei compagni di squadra). Se puoi sottolineare che nel tuo codice sono stati rilevati molti meno bug rispetto a quelli di altri, potresti avere un punto di forza da vendere sia al management che agli altri sviluppatori.

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

Il cliente ha un team di test ... beh, non c'è nessun problema a spostare l'onere dei test dallo sviluppatore ai tester - questo è ciò per cui sono lì dopo tutto, e se trovano bug durante i loro test (forse hanno un sacco di strumenti di test automatizzati) quindi non ha senso scrivere unità di test al tuo livello. Ci vorrà un po 'più tempo per trovare i bug, ma troveranno quei fastidiosi bug di "integrazione" che i tuoi test non avrebbero esercitato.

È probabile che questo sia 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 che ha funzionato. I test unitari fanno sentire alcune persone calde e confuse, ma non è assolutamente un requisito per un codice corretto.

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

Dal momento che tutto cambia così rapidamente mentre lo metti, spiega loro che verrà utilizzato per i test di regressione. Ciò consentirà di risparmiare molti mal di testa quando vengono introdotti nuovi bug perché qualcuno ha rotto una riga di codice scritta 10 anni fa per risolvere un problema che si verifica 1 su 10.000.000 di esecuzioni di una funzione specifica che viene chiamata solo se l'orologio di sistema è acceso il client ha una differenza maggiore di 3 minuti rispetto all'orologio di sistema del server. Basta chiedere loro quanti clienti possono permettersi di perdere a causa del software difettoso.

Fai notare che la ricerca di un bug durante lo sviluppo costa X, durante il test 10X e dopo la distribuzione 100X. Verifica se almeno ti permetteranno di condurre un test pilota in cui implementerai TDD in un modulo specifico, quindi segui i confronti con altri moduli mentre vengono sviluppati, testati, distribuiti e supportati. Dati adeguati, dovresti essere in grado di dimostrare quanto meno sforzo è stato fatto per produrre il codice nel modulo TDD. In bocca al lupo.

Sì, il mantenimento dei test è un peso. Aggiornandoli, aggiornando i tuoi dati di test: tutto ciò ti fa perdere tempo.

L'alternativa - testare manualmente le cose, correggere i bug che regrediscono, non riuscire a dire in pochi secondi che il codice funziona - costa molto di più.

Bene, il test è oneroso ma è un buon onere da trasportare. È meglio fare un po 'di lavoro in anticipo che risparmierebbe una buona quantità di tempo in caso di problemi di produzione o durante la migrazione. Avrò sempre voglia di fare il test anche se è un piccolo onere, ma voglio portare quel peso.