Introduci test unitari quando il codice base è già disponibile [duplicato]

Riscrivendo da zero solo per poter avere test automatici è sciocco - hai una base di codice che (soprattutto) funziona, e probabilmente puoi testarla (solo non automaticamente). Una riscrittura, anche con tutti i test nel mondo, comporta un rischio in più e richiede sempre più tempo del previsto. Quindi non farlo.

Anche scrivere test per ottenere una copertura del 100% in un colpo solo è sciocco, perché significa che si sta fermando lo sviluppo in corso per implementare qualcosa che non aggiunge ancora alcun valore. Nella maggior parte delle situazioni, questo è inaccettabile. Inoltre, scrivere test per il codice che funziona già e che non ha bisogno di cambiare ha poco beneficio se non verificare che funzioni davvero (ma se è in esecuzione in produzione, è meglio esserne già certi).

Il modo migliore per farlo, IMO, è aggiungere test man mano che procedi. Cioè, per ogni modifica che fai, applica i seguenti passaggi:

1. Verifica se i test esistenti descrivono sufficientemente la funzionalità corrente.
2. Se necessario, aggiungi test per acquisire la funzionalità corrente di quella particolare parte / modulo / classe / funzione / ... Verifica che superino.
3. Rif. codice esistente se necessario.
4. Modifica i test per riflettere il nuovo comportamento previsto.
5. Modifica il codice per far passare i test.
6. refactoring.

I passaggi da 4 a 6 sono solo TDD di base; l'unica aggiunta è che si aggiungono retroattivamente i test necessari prima di avviare il ciclo TDD effettivo.

Se segui questa procedura e i test che aggiungi nel passaggio 2 sono sufficienti, il codebase si sposterà gradualmente verso la copertura completa del test.

Naturalmente, se vuoi riscrivere comunque, per ragioni diverse, è probabile che iniziare subito a TDD dall'inizio sia una buona idea.

Il codice legacy è un codice funzionante, è stato testato in the wild. La cosa peggiore che puoi fare è buttarla via e sostituirla con un nuovo codice. Anche con il miglior nuovo codice (con ect TTD) avremo bug occasionali.

Cosa vorrei raccomandarlo ogni volta che colpisci un bug, crei un test unitario attorno a quella funzionalità. Il suo non molto lavoro extra quando si aggiustano le cose e vorrà dire che le aree più buggy avranno prima i test unitari.

Well, I would appreciate not having to write everything from scratch but I think by doing this, the design would be much better.

Questa è una supposizione molto sbagliata. I test non hanno nulla a che fare con il design. È necessario comprendere i vantaggi di TDD in maggiori dettagli.

Idealmente se hai un prodotto funzionante stabile che non richiede alcuna modifica, i casi di test non ti aiuteranno. I test automatici ti aiutano solo con il ri-factoring o l'aggiunta di funzionalità.

Per un progetto esistente, il modo migliore è analizzare la modifica (ri-factoring / feature / bug-fix) e quindi scrivere casi di test solo per quel codice.

EDIT: Non accetto il fatto che testare gli impatti. ma anche quando lo fa, abbiamo il problema dell'inversione dei fini. La progettazione dovrebbe essere basata sul dominio del problema e non sul test. TDD è solo un mezzo per raggiungere il fine, che in questo caso sta risolvendo il problema in mano.