È realistico chiedere al tuo team di raggiungere un obiettivo di copertura del test automatico al 100% come un'attività di allungamento?

Può essere possibile, ma devi chiedere, ne vale la pena?

Quando fai il TDD normale, passi del tempo a scrivere codice che non entra in produzione, ma il tempo è ben speso perché alla fine risparmi più tempo perché è più facile aggiungere nuove funzionalità e dedicare meno tempo a correggere i bug .

Ma quando retrofitting i test unitari su una base di codice legacy basata sull'obiettivo di raggiungere il 100% di copertura del codice, i test verranno spesso scritti per il motivo sbagliato. Puoi iniziare scrivendo un sacco di test basati sulla logica di business. Ma dopo aver raggiunto una certa copertura (credo tra il 60-80%), non si scrivono più test basati sulla logica aziendale, ma guardando l'analisi della copertura del codice, trovando linee di codice che non sono coperte. / p>

I test che coprono l'ultimo 20-40% di un costo elevato, alcuni motivi:

• Non hanno un valore reale
• Ci vuole un'enorme quantità di tempo per scrivere. Quando i test sono basati su regole aziendali, un singolo test coprirà in genere molte righe di codice. Una volta che inizi a scrivere test basati sull'analisi della copertura del codice, tendi a scrivere un test per ogni singola riga di codice scoperto.
• I test tendono a dover essere rifattorizzati molto spesso.

Ciò che devi anche sapere è che un sistema che non ha alcuna copertura di test non è probabilmente facile da testare per cominciare, quindi, semplicemente intraprendendo questo endavour, adattando i test unitari ad una base di codice esistente, la base di codice esistente ha essere refactored abbastanza pesantemente.

Quindi è realistico? Forse. È una buona idea? Non probabile.

No, non è realistico. Può essere fatto, ma richiederà molto più tempo, costa molto di più e farà molto di più (o anche meno) per la manutenibilità del progetto rispetto a un obiettivo più intelligente, ad es. 80% solo su quelle parti del sistema che sono state identificate come ad alto rischio.

Il problema è che un sistema che non è stato progettato per avere test automatici dall'inizio non è probabilmente molto trattabile per i test e può richiedere un sacco di refactoring per arrivarci, che è un'attività molto rischiosa. E questo problema sarà ingrandito di cento volte l'obiettivo è ottenere una copertura del 100% (nemmeno toccando il tema di test che aumentano la copertura, ma in realtà non testano nulla e sono quindi inutili).

Fondamentalmente, quando si tratta di test automatici, il codice può essere misurato su due assi ortogonali:

• Facile da test vs. difficile da testare
• Codice complesso, che cambia frequentemente e che trae vantaggio dal testing rispetto a un codice semplice e solido che non ha realmente bisogno di test

La posizione del codice su questi assi si traduce direttamente in un rapporto costi-benefici per i test. Il codice facile da seguire è dove dovresti iniziare, probabilmente seguito da rischioso (se la qualità è più importante e hai tempo a sufficienza) o facile-solido (se il costo conta o c'è una pressione limite). L'hard-solid code dovrebbe essere affrontato per ultimo, nella speranza che i test già esistenti rendano i refactoring necessari meno rischiosi, o che non vengano testati perché non ne vale la pena.

Dopo tutto, hai comunque bisogno di test manuali, poiché non tutto può essere automatizzato e non tutte le modalità di errore imprevisto possono essere rilevate da test automatici.

Supponendo che tu intenda l'intero codice base e non solo quello su cui stanno lavorando, mi sembra un obiettivo un po 'bizzarro - perché l'azienda è interessata a questo? Sta per generarli più soldi? E se lo scopo è quello di rendere il codice più resiliente alla modifica, presumibilmente la maggior parte delle modifiche interesserà solo una piccola parte di quelle 1.5M LOC e il tempo impiegato per aggiungere la copertura al resto è semplicemente sprecato.

Sarebbe meglio introdurre i test mentre si procede, isolando il codice che cambierà da quello che non sarà, insieme con alcuni test di integrazione su larga scala che rimbalzeranno all'avvio.

Il libro Trattare efficacemente con il codice legacy ha ottimi consigli in questo settore.

Come programmatore di un progetto del genere avrei qualche riserva.

In primo luogo, perché stiamo intraprendendo un simile progetto. Ci sono aggiunte programmate al progetto, oppure è in programma una rielaborazione importante. Testare per motivi di test è un obiettivo scadente e ucciderà la motivazione. Se c'è un strong obiettivo commerciale dietro al progetto, forse sarei felice di farlo.

In secondo luogo, una volta compreso l'obiettivo, la copertura è davvero il modo migliore in cui raggiungere questo obiettivo. Ci sono numerose critiche riguardo alla copertura del test LOC. Quali si applicano qui? Saremo semplicemente perdere tempo con quell'ultimo 10-20%. C'è un modo in cui possiamo partizionare il progetto per raggiungere in modo incrementale il nostro obiettivo primario?