Ho linee da 200k di codice mal progettato, i test di unità o di integrazione saranno più preziosi? [duplicare]

C'è un libro fantastico che copre ciò che stai facendo in grande profondità. Lavorare efficacemente con il codice legacy descrive una serie di tecniche per fare esattamente quello che stai facendo. Il sommario è disponibile qui . Mi era stato consigliato per anni e solo recentemente l'ho raccolto.

In sostanza, sì hai ragione. Prova per la funzionalità che dipenderà dagli utenti (o dai componenti che consumano), assicurandoti di poter coprire i casi limite quanto più umanamente possibile. I test unitari (tramite TDD) saranno utili per il nuovo codice che scriverai per sostituire il codice esistente, mentre i test di integrazione che hai scritto per coprire il codice esistente assicureranno che non stai rompendo nulla e continui a soddisfare il tuo contratti.

Non preoccuparti di ciò che viene chiamato il test - concentrati sul fatto che lo scopo dei test è quello di garantire che quando si effettua il refactoring il codice faccia ancora la stessa cosa.

Quindi scriverà test per due scopi:

1. Per assicurarti di non rompere la funzionalità esistente quando rifatti il codice esistente in qualcosa di più gestibile.
2. Per definire e testare la funzione del nuovo codice che aggiungi.

In teoria dovresti sempre fare l'uno o l'altro di questi - anche se la sfida è che probabilmente avrai bisogno di rifattorizzare il codice per facilitare l'aggiunta di nuove funzionalità e ulteriormente - se è davvero legacy - renderlo testabile in primo luogo (motivo per cui vi è un'enfasi sul refactoring e l'aggiunta di funzionalità come attività distinte).

In entrambi i casi si desidera aggiungere test a uno scopo - è improbabile che il codice venga rifattorizzato perché solo perché è possibile, si avranno obiettivi da raggiungere e i test scritti (unità, integrazione, qualunque) dovrebbero essere quelli necessari per sostenere il lavoro che ti spinge verso quell'obiettivo.

In questo caso penso che i test di regressione / integrazione sarebbero più utili. Ma vorresti comunque creare test unitari mentre esegui il refactoring. Inoltre, tieni presente che i test unitari servono a testare cosa si suppone debba fare una funzione, non ciò che fa attualmente. Quindi scrivi i tuoi test come se il codice fosse perfetto, quindi refactoring per rendere il codice adatto ai test.

Should I spend a lot of time putting unit tests into a design I will change dramatically?

Questo è discutibile. Se cambi radicalmente il design, potrei discutere semplicemente lasciando il vecchio codice così com'è e scrivendolo di nuovo. 200kloc non è tanto nel grande schema delle cose. Se non stai modificando il vecchio codice, l'unità di test è probabilmente senza valore.

Se lo stai modificando in qualsiasi modo, i test unitari (probabilmente) ti faranno risparmiare tempo e fatica.

Wont those unit tests be useless after a major redesign?

Certo, ma durante la riprogettazione, sono inestimabili.