I generatori di unit test ti hanno aiutato quando hai lavorato con il codice legacy?

Sto osservando una piccola base di codici (# 70kLOC inclusi) C # (.NET 4.0, alcuni Silverlight) con una copertura di test molto bassa. Il codice stesso funziona in quanto ha superato i test di accettazione dell'utente, ma è fragile e in alcune aree non molto ben preso in considerazione. Vorrei aggiungere una solida copertura di test unitari attorno al codice legacy usando i soliti sospetti (NMock, NUnit, StatLight per i bit Silverlight).

Il mio approccio normale è iniziare a lavorare attraverso il progetto, unit testing e refactoring, fino a quando non sono soddisfatto dello stato del codice. L'ho fatto molte volte in passato e ha funzionato bene.

Tuttavia, questa volta sto pensando di utilizzare un generatore di test (in particolare Pex ) per creare il framework di test, quindi completarlo manualmente.

La mia domanda è: hai usato generatori di unit test in passato quando hai iniziato a lavorare su una base di codice legacy e, in tal caso, li consiglieresti?

La mia paura è che i test generati manchino le sfumature semantiche della base di codice, portando alla temuta situazione di avere test per il bene della metrica di copertura, piuttosto che test che esprimono chiaramente il comportamento previsto nel codice.

unit-testing legacy

— Duncan Bayne
fonte

Ho provato PeX una volta e i risultati erano, beh, diciamo, non molto soddisfacenti: YMMV. Non aspettarti che uno strumento del genere "comprenda" il tuo codice e i suoi requisiti funzionali: non manca solo di "sfumature semantiche", manca l'intera semantica. Inoltre, quando inizi con una base di codice legacy, in genere non inizierai prima con i test unitari, ma con i test di sistema o di integrazione; questo è sicuramente niente per cui PeX è stato creato.

— Doc Brown,

Suggerirei di guardare le cose in modo leggermente diverso. L'aggiunta di un nuovo codice di test unitario a un'applicazione esistente senza incidenti potrebbe non fornire i migliori risultati. Se lo stai facendo per familiarizzare con la base di codice o hai davvero tempo per uccidere e vuoi testare i generatori di test, ignora i miei commenti.

Per essere pragmatico, dovresti esaminare tutte le liste di bug. Quindi creare unit test per ciascuno dei bug, determinando come dovrebbe comportarsi. Idealmente, aggiungerei un nuovo codice per ogni bug man mano che lo raggiungi.

Tempi per aggiungere il codice unit test:

Aggiunta di nuove funzionalità
Codice ricodificato
Risolto un bug
Imparare cosa fa il codice
Prova che esiste un bug

È difficile quantificare il valore dell'aggiunta di unit test dopo il fatto.

Di solito non mi permetto di scrivere risposte contrarie a ciò che vuole chi chiede, ma ritengo che questa sia una buona lezione da trasmettere.

— Andrew T Finnell
fonte

Sono d'accordo al 100% con te lì - questa domanda è nata da me chiedendomi come trascorrere un po 'di tempo libero. La mia pratica normale è testare e refactoring nel processo di correzione dei bug o aggiunta di funzionalità. Speravo che alcune persone potessero condividere alcune storie di guerra in quest'area ...

— Duncan Bayne,

+1, sparare per la copertura dopo il fatto di solito non è produttivo. Avere test su bug corretti che impediscono la regressione è molto produttivo. La regressione di un bug può essere molto frustrante per tutti i soggetti coinvolti. I test sono davvero adatti per aiutarti a scrivere codice migliore. L'avvitamento dei test di solito comporta test scadenti. Penso che la paura dell'OP sia fondata e il rapporto segnale-rumore dai test generati si metterà di mezzo. Il codice non testato probabilmente contiene alcuni bit molto ramificati. Gli strumenti che indicano gli odori del codice sono probabilmente più utili. Forse FXCop e strumenti simili.

— Kevinev