Best practice per l'aggiornamento del codice legacy con test automatici

Naviga le tue risposte
21

Sto per assumere il compito di reimplementare un'interfaccia già definita (un insieme di file di intestazione C ++) in una base di codice relativamente grande e vecchia. Prima di fare questo, vorrei avere la copertura di test più completa possibile, in modo da poter rilevare gli errori di reimplementation nel modo più rapido e semplice possibile. Il problema è che il codice base già esistente non è stato progettato per essere facilmente testabile, con classi e funzioni (molto) grandi, un alto grado di accoppiamento, funzioni con (molti) effetti collaterali, ecc.

Sarebbe bello sapere di qualsiasi esperienza precedente con attività simili e alcuni buoni e concreti suggerimenti su come è stato eseguito l'adeguamento dei test automatici (unità, integrazioni, regressione, ecc.) al codice legacy.

    
posta tjansson 27.01.2011 - 09:23
fonte

4 risposte

20

Prima di tutto, ottieni e leggi Lavorare efficacemente con il codice legacy di Michael Feathers - è un aiuto indispensabile per tali compiti.

Quindi, alcune note:

  • hai una precisa specifica / contratto per l'interfaccia, o hai praticamente solo l'implementazione esistente come "specifica"? Nel primo caso è più facile eseguire una riscrittura completa da zero, nel secondo è difficile impossibile.
  • se vuoi reimplementare l'interfaccia, il modo più utile per spendere le tue risorse di test è scrivere test solo contro l'interfaccia. Naturalmente, questo non si qualifica come test unitario in senso stretto, piuttosto come test funzionale / di accettazione, ma non sono un purista :-) Tuttavia, questi test sono riutilizzabili e consentono di confrontare direttamente i risultati delle due implementazioni fianco a fianco .
  • nel complesso, preferirei rifattorizzare il codice esistente piuttosto che riscrivere da zero, a meno che non sia completamente impossibile da mantenere. (Ma in questo caso, come hai intenzione di scrivere test unitari contro di esso in ogni caso?) Controlla questo post di Joel per una discussione più dettagliata sull'argomento. Avendo creato una serie di test di accettazione sull'interfaccia, si ottiene una rete di sicurezza sottile, ma utile, contro la quale è possibile iniziare con cautela il refactoring del codice esistente per renderlo testabile dell'unità (usando le idee del libro di Feathers).
risposta data 27.01.2011 - 09:32
fonte
4

Il metodo migliore è sapere è il metodo Mikado. link Questa è solo la generalizzazione di una semplice tecnica, ma è l'unico modo che conosco per iniziare a migliorare la qualità del codice in una grande base di codici senza correre rischi inutili.

WEWLC è anche un ottimo libro a riguardo ma scrivere in C ++ non è sempre utile con codice Java o Ruby.

    
risposta data 27.01.2011 - 12:31
fonte
2

I test di adattamento retrò su una vecchia base di codice possono essere abbastanza difficili se sono monolitici nella progettazione.

Se possibile (hai tempo / denaro), un modo per andare avanti sarebbe refactoring del codice in unità più testabili.

    
risposta data 27.01.2011 - 09:30
fonte
1

Vorrei aggiungere un collegamento . Ci sono alcuni esempi di implementazioni non così facilmente verificabili rielaborate in un codice più xUnit amichevole. Per quanto riguarda l'approccio generale vai a provare i link già menzionati (Joel post, Working With Legacy code

    
risposta data 28.01.2011 - 15:39
fonte

Leggi altre domande sui tag

In che modo Node.js è diverso dagli altri framework lato server? In che modo l'utilizzo di una gemma LGPL influenza la mia applicazione con licenza MIT?