Spostamento del codice esistente in Test Driven Development

Question

Avendo recentemente scoperto questo metodo di sviluppo, lo trovo una metodologia piuttosto piacevole. Quindi, per il mio primo progetto, ho una piccola quantità di codice DLL (in C # .NET, per quello che vale) e voglio fare una serie di test per questo codice, ma mi sono un po 'perso su come e da dove iniziare.

Sto usando NUnit e VS 2008, tutti i suggerimenti su quale tipo di classi per iniziare, su cosa scrivere i test e tutti i suggerimenti su come passare il codice attraverso lo sviluppo basato su test sarebbero molto apprezzati .

Answer 1

Vedi il libro Lavorare in modo efficace con il codice legacy di Michael Feathers.

In sintesi, è molto lavoro rifattorizzare il codice esistente in codice testabile e testato; A volte è troppo lavoro per essere pratico. Dipende da quanto è grande la base di codice e da quanto le varie classi e funzioni dipendono l'una dall'altra.

Il refactoring senza test introdurrà cambiamenti nel comportamento (ad es. bug). E i puristi diranno che non è proprio il refactoring a causa della mancanza di test per verificare che il comportamento non cambi.

Piuttosto che aggiungere test su tutta la linea all'intera applicazione in una volta, aggiungi test quando lavori in un'area di codice. Molto probabilmente dovrai tornare a questi "hotspot". ancora una volta.

Aggiungi test dal basso verso l'alto: verifica la correttezza di classi e funzioni indipendenti.

Aggiungi test dall'alto verso il basso: testa interi sottosistemi come caselle nere per vedere se il loro comportamento cambia con le modifiche al codice. E così puoi esaminarli per scoprire cosa sta succedendo. Questo approccio probabilmente ti darà il massimo beneficio.

All'inizio non preoccuparti troppo di cosa il "corretto" il comportamento è durante l'aggiunta di test, cerca di rilevare ed evitare cambiamenti nel comportamento. I sistemi di grandi dimensioni non testati hanno spesso comportamenti interni che possono sembrare errati, ma da cui dipendono altre parti del sistema.

Pensa a isolare dipendenze come database, filesystem, rete, in modo che possano essere sostituite da provider di dati finti durante i test.

Se il programma non ha interfacce interne, linee che definiscono il confine tra un sottosistema / livello e un altro, potrebbe essere necessario provare a introdurli e testarli.

Inoltre, framework di derisione automatici come Rhinomocks o Moq potrebbe aiutare a deridere le classi esistenti qui. Non ho davvero trovato la necessità per loro nel codice progettato per la testabilità.

Answer 2

Lavorare in modo efficace con il codice legacy è la mia bibbia quando si tratta di migrare il codice senza test in un ambiente testato dall'unità e fornisce anche molte informazioni su ciò che rende il codice facile da testare e su come testarlo.

Ho anche trovato Test Driven Development con l'esempio e Pragmatic Unit Testing: in C # con NUnit per essere una buona introduzione ai test unitari in quell'ambiente.

Un semplice approccio all'avvio di TDD è iniziare a scrivere i test da questo giorno in poi e assicurarsi che ogni volta che è necessario toccare il codice esistente (non testato dall'unità), si scrivano test di superamento che verificano il comportamento esistente del sistema prima di modificarlo in modo da poter rieseguire quei test dopo per aumentare la sicurezza di non aver rotto nulla.

Answer 3

Lo chiamo " Test Driven Reverse Engineering " ;.

Inizia " in fondo " - ogni classe può essere esaminata separatamente e una prova scritta per essa. In caso di dubbi, indovina.

Quando si esegue un normale TDD in avanti, si considera sacro il test e si presume che il codice sia probabilmente rotto. A volte il test è sbagliato, ma la tua posizione di partenza è che è il codice.

Quando fai TDRE, il codice è sacro - finché non puoi provare che il codice ha un bug di vecchia data. Nel caso contrario, scrivi i test attorno al codice, modificando i test fino a quando funzionano e rivendichi che il codice funzioni.

Quindi, puoi scavare nel codice errato. Alcuni cade cattivi avranno casi di test sensati - questo deve solo essere ripulito. Alcuni codici errati, tuttavia, avranno anche un caso di test insensato. Potrebbe trattarsi di un bug o di un disegno goffo che potresti essere in grado di correggere.

Per giudicare se il codice è effettivamente sbagliato, devi anche iniziare dall'alto con casi di test generali. I dati in tempo reale che funzionano effettivamente sono un inizio. Inoltre, i dati in tempo reale che producono uno qualsiasi dei bug noti, anche un buon punto di partenza.

Ho scritto piccoli generatori di codice per trasformare i dati in tempo reale in casi meno complicati. In questo modo, ho una base coerente per i test e il refactoring.

Answer 4

Il codice testabile è facile da individuare - dai test di accompagnamento. Se ce ne sono alcuni, deve essere testabile. Se non ce ne sono, supponiamo il contrario. ;)

Detto questo: Test Driven Development (TDD) non è tanto una strategia di test quanto una strategia di progettazione. I test che scrivi per primi aiutano a progettare l'interfaccia delle tue classi, così come a capire bene l'ambito delle tue classi (o sottosistemi).

Avere i test che hai creato durante TDD ed eseguirli in seguito rende buoni test, ma è semplicemente un effetto collaterale (molto gradito) di quella filosofia di progettazione.

Detto questo, aspettati una certa resistenza dal tuo codice per non essere testato. Ascolta il tuo codice e cambia l'interfaccia per essere facilmente testabile. Molto probabilmente lo ridisegnerai quando inizi a scrivere test.

Answer 5

La tua DLL fornisce una sorta di servizio. Per ogni servizio, cosa devi fare prima di ottenere questo servizio, quali parametri dovresti passare per ottenere questo servizio, come faresti a sapere se il servizio richiesto è stato eseguito correttamente?

Una volta che hai le risposte a queste domande, puoi scrivere un primo test. Tali test sarebbero piuttosto chiamati Test di caratterizzazione che test unitari, ma probabilmente lo sarebbero più facile da scrivere rispetto ai test unitari se la DLL non è stata sviluppata utilizzando TDD.

I test di caratterizzazione sono anche discussi in M. Feathers "Lavorare in modo efficace con il codice legacy", che è raccomandato in altre risposte.

Inoltre, assicurarsi di scrivere un test non riuscito prima di aggiungere una nuova riga di codice.