Devo continuare a registrare un errore?

Question

Sto lavorando a una suite di test di regressione automatizzata per un'app che mantengo. Durante lo sviluppo del test di regressione automatizzato, mi sono imbattuto in un comportamento che è quasi certamente un bug. Quindi, per ora, ho modificato il test di regressione automatizzato per non registrare un errore: è deliberatamente permettendo a questo cattivo comportamento di andare avanti, voglio dire.

Quindi, sono interessato alle opinioni degli altri su questo sito. Ovviamente, aggiungerò un bug al nostro monitoraggio dei difetti per assicurarmi che questo comportamento di errore venga corretto. Ma ci sono motivi validi (in entrambi i casi) per cambiare il test di regressione per indicare costantemente il fallimento o lasciare il test di regressione rotto e non avere un fallimento fino a quando non possiamo arrivare a correggere il comportamento difettoso? Penso a questo come a 6 di una mezza dozzina dell'altro tipo di domanda, ma chiedo qui perché pensavo che gli altri potessero vederlo in modo diverso.

---

@ Paolo Tomblin,

Giusto per essere chiari - non ho mai considerato la rimozione della prova; Stavo semplicemente considerando la possibilità di modificare la condizione pass/fail per consentire il fallimento senza che mi venga a galla in faccia ogni volta che eseguo il test.

Sono un po 'preoccupato per i ripetuti guasti da cause conosciute che alla fine vengono trattati come avvertimenti in C++. Conosco sviluppatori che vedono gli avvertimenti nel loro codice C++ e semplicemente li ignorano perché pensano che siano solo un rumore inutile. Temo che lasciare un errore noto nella suite di regressione possa far sì che le persone inizino a ignorare altri, forse più importanti, fallimenti.

BTW, per non essere frainteso, considero gli avvertimenti in C++ come un aiuto importante nella creazione di codice forte ma a giudicare dagli altri sviluppatori C++ che ho incontrato penso di essere in minoranza.

Answer 1

Direi "diavolo si!". Il semplice fatto è che sta fallendo? Sì! Quindi dovrebbe essere registrato. Stai praticamente compromettendo i tuoi test consentendo il superamento di un test fallito.

Una cosa che mi riguarda personalmente, è che se l'ho fatto, e sono andato sotto un bus, allora la "patch" non può essere rimossa, il che significa che anche dopo una "correzione" il bug può ancora rimanere.

lasciarlo in, aggiornare le note di progetto, forse anche spostare la gravità verso il basso (se possibile), ma certamente dont rompere la cosa che sta controllando per le cose rotte;)

Answer 2

Se smetti di provarlo, come farai a sapere quando è stato corretto e, cosa ancora più importante, come farai a sapere se si rompe di nuovo? Sono contrario a portare fuori il test, perché è probabile che tu dimentichi di aggiungerlo di nuovo.

Answer 3

dovrebbe rimanere un fallimento se non è facendo ciò che ci si aspettava.

Altrimenti, è troppo facile da ignorare. Mantieni le cose semplici: funziona o no. Fail o il successo :)

- Kevin Fairchild

Answer 4

Avere un test in mancanza è una specie di reticolo. C'è una differenza tra codice spezzato e codice incompleto, e se il test deve essere indirizzato immediatamente dipende da quale circostanza mostra questo test non riuscito.

Se è rotto, è necessario correggerlo prima piuttosto che dopo. Se è incompleto, affrontalo quando hai tempo.

In entrambi i casi, è chiaro che si può vivere con esso comportandosi male (per ora), quindi finché il problema viene registrato si potrebbe anche non averlo tormentarlo fino a quando non si ha il tempo di risolverlo.

Answer 5

Mentre concordo con la maggior parte di ciò che Paolo ha detto, l'altra parte dell'argomento sarebbe che i test di regressione, in senso stretto, dovessero verificare i cambiamenti nel comportamento del programma, non solo un vecchio bug. In particolare, dovrebbero dirti quando hai rotto qualcosa che prima funzionava.

Penso che questo si riduce a quello che altri tipi di test vengono eseguiti su questa app. Se si dispone di una sorta di sistema di test unitario, forse questo sarebbe un posto più appropriato per questo test, piuttosto che nel test di regressione (almeno fino a quando il bug non verrà corretto). Se i test di regressione sono i tuoi unici test, tuttavia, probabilmente lascerei il test in atto.

Answer 6

Abbiamo aggiunto una funzione "snooze" ai nostri test di unità. Ciò ha permesso di annotare un test con un attributo che sostanzialmente diceva "ignorare i fallimenti per X settimane a partire da questa data". Gli sviluppatori potevano annotare un test che sapevano non sarebbe stato corretto per un po 'di tempo con questo, ma non richiedeva alcun intervento in futuro per riattivarlo manualmente, il test tornava semplicemente nella suite di test all'ora stabilita.

Answer 7

Mentre è meglio che i test falliscano quando ci sono errori, questa è spesso una scelta poco pratica. Quando si aggiunge per la prima volta un test ad un'area, è particolarmente facile impantanarsi nei bug che si scoprono e che quindi non portano a termine l'obiettivo primario. Inoltre, i test a lungo termine diventano così tanto rumorosi, facili e facili da ignorare.

La scrittura dei test di errore è parte del bug di correzione, ed è molto importante quando correggere questi bug è importante. Questo dovrebbe essere determinato dal tuo attuale prodotto e dalle priorità di qualità. Se ti capita di produrre test come effetto collaterale di qualche altro sforzo, è bello, ma non dovrebbe essere permesso di distrarti dalle tue priorità reali.

Si consiglia di segnalare eventuali bug durante il miglioramento dei test in avvisi e bug di archiviazione contro di essi. È un approccio di ampia portata che ti consentirà di superare l'attività corrente e di utilizzare effettivamente ciò che impari. I test possono quindi essere facilmente trasformati in errori reali quando gli errori sono programmati per il fixing.

A differenza di altri intervistati, penso che i fallimenti siano altrettanto facili da ignorare come avvertenze e il costo dell'allenamento del team per ignorare i guasti è troppo alto per consentire che ciò accada. Se si producono test falliti come parte di questo impegno, si avrà distrutto l'utilità della propria suite di test di regressione quando l'attività è stata migliorata.