TDD / Test troppo sovraccarico / oneri di manutenzione?

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.

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.

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:)

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.

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.

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ù.

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.