Test di unità obsoleti / legacy interrotti

Quello che vorrei fare è disabilitare per prima cosa i test che hanno fallito e hanno sempre fallito.

Fai in modo che un test non funzioni.

Mentre indaghi potresti essere in grado di chiedere a persone che sono state con la tua compagnia più a lungo su di loro, potrebbero esserci molte conoscenze tribali su di loro che puoi documentare / catturare. Forse dai tuoi log VCS. "Oh, quel test è sempre fallito da quando abbiamo aggiornato a X" o altre informazioni possono essere utili.

Una volta che sai quale funzionalità è stata testata, puoi determinare:

• Ci interessa che venga testato
• Quanto è importante testare

Quindi crea un elenco di priorità.

Probabilmente niente di questo elenco è abbastanza importante da ottenere più tempo dopo poiché è stato ignorato per anni. Quindi non spenderei troppo molto tempo / risorse per documentare e analizzare tutti questi test non funzionanti.

Farei quanto segue:

1. Tentativo di determinare esattamente quali test falliscono tentano di convalidare.

2. Triage - se alcuni test stanno cercando di testare cose non importanti come (un vecchio) stato del mondo, cancellali. Se ti accorgi che alcuni di loro stanno cercando di convalidare qualcosa di importante, prova a determinare se quei test lo stanno facendo correttamente. Se stanno testando in modo errato, fallo testare correttamente.

3. Correggi qualsiasi problema con il tuo codice di produzione ora che hai dei buoni test.

Ricorda contabilità, ogni riga di codice è una responsabilità, ma può essere erroneamente valutata come una risorsa. La chiave delete può creare molto valore per la tua azienda.

200-300 broken tests (likely broken for years).

Ouch! Ho affrontato una situazione simile una volta, ma con 7 test fallendo il punto in cui la squadra ha iniziato a ignorare il fatto che non ci sono riusciti per mesi a causa della mentalità "always-crunch".

My goal is 100% passing tests so we can break the build on unit test failures, but I can't do it until I address the broken tests.

Ero ossessionato da un obiettivo simile anche se ero solo uno sviluppatore junior nel team perché stavo notando un accumulo di pile in cui altri test stavano fallendo nel corso dei mesi. Volevo che trasformassimo quelli da "avvertenze" in errori di compilazione (forse un po 'odioso per il resto della squadra).

I'm thinking we should document the statuses of the broken tests with anything we know, then either delete or ignore the broken tests completely and enter a lower-priority bug/work item to investigate and fix them. We'll then be at 100% and start to get real value out of the other tests and if we have a maintenance/refactoring windfall we'll be able to pick them up again.

Questi sono anche i miei pensieri. È possibile disabilitare temporaneamente tutti questi test difettosi e visitarli lentamente e correggerli nel tempo. È importante pianificare queste correzioni se le consideri davvero importanti, anche se hanno una bassa priorità, dal momento che è facile che tali elementi rimangano semplicemente non fissati. La priorità per me è assicurarsi che non vengano introdotti nuovi test che falliscono.

Come ogni tipo di avvertimento, se non rompono la build, tendono ad accumularsi rapidamente. Ciò presuppone quel tipo di dinamico di squadra in cui l'abitudine di ignorare gli avvertimenti (test falliti in questo caso) può portare rapidamente a ulteriori avvertimenti introdotti e ridurre la tentazione di mantenere tali avvisi a zero.

Un team molto coscienzioso potrebbe non soffrire di questi problemi ed evitare di introdurre nuovi avvertimenti (nuovi fallimenti nei test), ma è sicuramente più sicuro andare un po 'più pesante ed esercitare una strategia di prevenzione trasformandoli in errori che deve essere corretto prima di un processo di fusione.

Quindi il mio suggerimento è lo stesso del tuo (anche se solo una strong opinione - forse un po 'può confermarlo con le metriche e una risposta più scientifica). Disabilita quei vecchi test e mettili in programma per risolverli. La prima priorità è assicurarsi che questo problema non si accumuli e inizi a peggiorare assicurandoti che i test che attualmente hanno successo non finiscano per essere ignorati se iniziano a fallire.

In un certo senso sei fortunato. È meglio avere test che falliscono e non dovrebbero (ti danno almeno un avvertimento che qualcosa non va) piuttosto che avere test che passano e non devono (che ti danno un falso senso di sicurezza).
Naturalmente se hai il primo è molto probabile che tu abbia anche quest'ultimo (quindi test che passano ma dovrebbero fallire).

Come già detto, per ora disabilitiamo quei test falliti, ma invitiamo loro a stampare un messaggio nel registro di test come promemoria costante su di loro.
Ma dovresti sicuramente trovare le risorse per andare oltre l'intera suite di test per trovare e eliminare i test che passano e non dovrebbero, perché ognuno di essi significa che c'è un errore nel codice che non stai attualmente rilevando nel tuo cicli di test.

Usando quel cloud oscuro che pende dal codice base potresti essere in grado di ottenere un budget per una revisione completa dei tuoi test, se giochi bene e non basta dire loro che pensi che alcuni test dovrebbero essere guardati perché sembrano fallire quando non dovrebbero, ma che non ti fidi che i tuoi test rilevano correttamente errori nel tuo codice, che il set di test non può essere considerato affidabile per svolgere il suo lavoro.
Quando l'ho fatto in una precedente azienda che stavo lavorando per una recensione del genere ho riscontrato che centinaia di test sono stati scritti con ipotesi errate su ciò che il codice DOVREBBE fare, portando al codice (che è stato scritto usando le stesse assunzioni errate) superato i test quando davvero non dovrebbe avere. Risolvendo questo problema, sono stati risolti molti bug insidiosi che, sebbene la maggior parte non fossero critici, avrebbero potuto far crollare alcuni sistemi importanti.

Qualsiasi test dell'unità fallito dovrebbe causare la rottura del build. Buon per te per averlo realizzato e aver stabilito questo obiettivo. La mente umana difficilmente può ignorare qualcosa di più completo della fonte di un falso allarme persistente .

Getti via questi test e non guardare indietro. Se hanno fallito per anni e non sono stati contattati ora, non sono una priorità.

Per quanto riguarda la conoscenza tribale, se le persone con la conoscenza tribale sono ancora in giro, dovrebbero aver risolto i test falliti. In caso contrario, di nuovo, queste non sono una priorità.

Se non ci sono conoscenze tribali, tu e il tuo team dovete prendere possesso della logica. I test falliti possono essere più fuorvianti che utili - il mondo potrebbe essere andato avanti.

Crea nuovi test che siano rilevanti e vai avanti scrivendo un codice fantastico.