È possibile introdurre Test Driven Development (TDD) in un progetto maturo? [chiuso]

Question

• Supponiamo che abbiamo realizzato un valore di TDD troppo tardi. Il progetto è già maturo, molti clienti hanno iniziato a usarlo.
• Supponiamo che i test automatici utilizzati siano per lo più test funzionali / di sistema e ci sono molti test GUI automatizzati.
• Supponiamo che abbiamo nuove richieste di funzionalità e nuove segnalazioni di bug (!). Quindi buona parte dello sviluppo continua ancora.
• Nota che ci sarebbe già un sacco di oggetti business senza test unitari o piccoli.
• Troppe collaborazioni / relazioni tra loro, che vengono nuovamente testate solo attraverso test funzionali / di sistema di livello superiore. Nessun test di integrazione in sé.
• Grandi database in atto con molte tabelle, viste, ecc. Solo per creare un'istanza di un singolo oggetto business sono già disponibili numerosi round trip di database.

Come possiamo introdurre TDD in questa fase?

Il derisione sembra essere la strada da percorrere. Ma la quantità di derisione che dobbiamo fare qui sembra troppo. Sembra che l'infrastruttura elaborata debba essere sviluppata per il sistema beffardo che funziona per cose esistenti (BO, database, ecc.).

Significa che TDD è una metodologia adatta solo quando si parte da zero? Sono interessato a conoscere le possibili strategie per introdurre il TDD in un prodotto già maturo.

Answer 1

La creazione di una complessa infrastruttura beffarda nasconderà probabilmente i problemi nel tuo codice. Ti consiglierei di iniziare con i test di integrazione, con un database di test, attorno alle aree della base di codice che intendi modificare. Una volta che hai abbastanza test per assicurarti di non interrompere nulla se apporti una modifica, puoi iniziare a riformattare il codice per renderlo più testabile.

Vedi anche l'eccellente libro di Michael Feathers Lavorare efficacemente con il codice legacy , è un deve leggere per chiunque stia pensando di introdurre TDD in una base di codice legacy.

Answer 2

Penso che sia assolutamente possibile introdurre TDD in un'applicazione esistente, in effetti l'ho fatto di recente da solo.

È più semplice codificare nuove funzionalità in modo TDD e ristrutturare il codice esistente per adattarlo. In questo modo si inizia con una piccola sezione del codice testata, ma gli effetti iniziano a diffondersi nell'intera base di codice.

Se hai un bug, allora scrivi un test unitario per riprodurlo, riformattando il codice come necessario (a meno che lo sforzo non valga davvero la pena).

Personalmente, non penso che ci sia bisogno di impazzire e provare ad aggiornare i test nel sistema esistente in quanto ciò può essere molto noioso senza un grande beneficio.

In breve, inizia in piccolo e il tuo progetto diventerà sempre più infetto da test.

Answer 3

Sì, puoi. Dalla tua descrizione il progetto è in buone condizioni: una buona quantità di automazione dei test funzionali è la strada da percorrere! Per alcuni aspetti è ancora più utile dei test unitari. Ricorda che TDD! = Unit testing, si tratta di brevi iterazioni e solidi criteri di accettazione.

Ricorda che avere un progetto esistente e accettato in realtà semplifica i test: l'applicazione funzionante è la specifica dei requisiti migliori. Quindi sei in una posizione migliore rispetto a qualcuno che ha solo un pezzo di carta con cui lavorare.

Inizia a lavorare sui tuoi nuovi requisiti / correzioni di bug con un TDD. Ricorda che ci sarà un overhead associato al cambio della metodologia (assicurati che i tuoi clienti ne siano consapevoli!) E probabilmente si aspettino una buona dose di riluttanza dai membri del team che sono abituati ai "buoni vecchi metodi".

Non toccare le cose vecchie a meno che non sia necessario. Se avrai una richiesta di miglioramento che influenzerà le cose esistenti, considera i tempi supplementari per eseguire le operazioni di configurazione extra.

Personalmente non vedo molto valore nell'introdurre un'infrastruttura complessa per i modelli - sicuramente c'è un modo per ottenere gli stessi risultati in una modalità leggera ma ovviamente dipende dalle circostanze

Answer 4

Uno strumento che può aiutarti a testare il codice legacy (supponendo che tu non possa avere il tempo di rifattorizzarlo, è Typemock Isolator: Typemock.com Permette di iniettare dipendenze nel codice esistente senza la necessità di estrarre interfacce e simili perché non utilizza tecniche di riflessione standard (proxy dinamico ecc.) Ma utilizza invece le API del profiler. È stato utilizzato per testare app che si basano su sharepoint, HTTPContext e altre aree problematiche. Ti consiglio di dare un'occhiata. (Lavoro come sviluppatore in quella società, ma è l'unico strumento che non ti costringe a riformattare il codice legacy esistente, risparmiando tempo e denaro) Consiglio vivamente anche "Lavorare in modo efficace con il codice legacy" per ulteriori tecniche.

Roy

Answer 5

Sì, puoi. Non farlo tutto in una volta, ma introduce solo ciò di cui hai bisogno per testare un modulo ogni volta che lo tocchi.

Puoi anche iniziare con test di accettazione di più alto livello e proseguire fino a lì (dai un'occhiata a Fitnesse per questo).

Answer 6

Vorrei iniziare con alcuni test di integrazione di base. Questo riceverà il buy-in dal resto dello staff. Quindi iniziare a separare le parti del codice che hanno dipendenze. Lavora verso l'utilizzo di Dependency Injection in quanto renderà il tuo codice molto più testabile. Considera i bug come un'opportunità per scrivere codice testabile.