Come gestite i test di unità / regressione che dovrebbero fallire durante lo sviluppo?

https://stackoverflow.com/questions/155911

automated-tests

03-07-2019
|

Domanda

Durante lo sviluppo del software, potrebbero esserci dei bug nella base di codice che sono problemi noti. Questi bug causeranno il fallimento della regressione / test unitari, se i test sono stati scritti bene.

C'è un dibattito costante nei nostri team su come gestire i test falliti:

Commenta i casi di test non riusciti con un commento REVISIT o TODO.
- Vantaggio : sapremo sempre quando è stato introdotto un nuovo difetto e nessuno di cui siamo già a conoscenza.
- Svantaggio : potrebbe dimenticare di REVISITARE il caso di test commentato, il che significa che il difetto potrebbe scivolare attraverso le fessure.
Lascia i casi di test falliti.
- Vantaggio : non dimenticherai di correggere i difetti, poiché gli errori dello script ti ricorderanno costantemente che è presente un difetto.
- Svantaggio : Difficile rilevare quando viene introdotto un nuovo difetto, a causa del rumore di guasto.

Vorrei esplorare quali sono le migliori pratiche in questo senso. Personalmente, penso che una soluzione a tre stati sia la migliore per determinare se uno script sta passando. Ad esempio, quando esegui uno script, potresti vedere quanto segue:

Percentuale superata: 75%
Percentuale non riuscita (prevista): 20%
Percentuale non riuscita (imprevista): 5%

Dovresti in sostanza contrassegnare tutti i casi di test che prevedi non riescano (a causa di un difetto) con alcuni metadati. Questo ti assicura di vedere ancora il risultato del fallimento alla fine del test, ma di sapere immediatamente se c'è un nuovo fallimento che non ti aspettavi. Questo sembra prendere le parti migliori delle 2 proposte di cui sopra.

Qualcuno ha le migliori pratiche per gestirlo?

Soluzione

Lascerei i tuoi casi di test. Nella mia esperienza, commentando il codice con qualcosa come

// TODO:  fix test case

è simile a fare:

// HAHA: you'll never revisit me

In tutta serietà, man mano che ti avvicini alla spedizione, il desiderio di rivisitare TODO nel codice tende a svanire, specialmente con cose come i test unitari perché ti stai concentrando sulla correzione di altre parti del codice.

Lascia i test forse con il tuo " tri-state " soluzione. Comunque, incoraggerei fortemente a risolvere quei casi al più presto. Il mio problema con costanti promemoria è che dopo che le persone li vedono, tendono a sbirciare su di loro e dire " oh sì, abbiamo sempre quegli errori ... "

Caso in questione: in alcuni dei nostri codici, abbiamo introdotto l'idea di "asserzioni ignorabili". - afferma che sono lì per farti sapere che c'è un problema, ma consente ai nostri tester di passare oltre nel resto del codice. Siamo venuti a scoprire che il QA ha iniziato a dire cose come " oh sì, lo affermiamo continuamente e ci è stato detto che era ignorabile " e i bug non sono stati segnalati.

Immagino che ciò che sto suggerendo sia che esiste un'altra alternativa, che è quella di correggere i bug che i tuoi casi di test trovano immediatamente. Potrebbero esserci ragioni pratiche per non farlo, ma prendere l'abitudine ora potrebbe essere più vantaggioso a lungo termine.

Altri suggerimenti

Correggi subito il bug.

Se è troppo complesso da fare subito, probabilmente è un'unità troppo grande per il test unitario.

Perdere il test unitario e inserire il difetto nel database dei bug. In questo modo ha visibilità, può essere prioritario, ecc.

Lavoro generalmente nei moduli Perl e Perl's Test :: * che consentono di inserire blocchi TODO:

TODO: {
  local $TODO = "This has not been implemented yet."

  # Tests expected to fail go here
}

Nell'output dettagliato dell'esecuzione del test, il messaggio in $ TODO viene aggiunto al rapporto pass / fail per ogni test nel blocco TODO, in modo da spiegare perché ci si aspettava che fallisse. Per il riepilogo dei risultati dei test, tutti i test TODO vengono considerati come riusciti, ma, se qualcuno effettivamente restituisce un risultato positivo, il riepilogo conteggerà anche quelli e riporterà il numero di test che hanno avuto successo inaspettatamente.

La mia raccomandazione, quindi, sarebbe quella di trovare uno strumento di test che abbia capacità simili. (O semplicemente usa Perl per i tuoi test, anche se il codice da testare è in un'altra lingua ...)

Abbiamo fatto quanto segue: metti una gerarchia nei test.

Esempio: devi testare 3 cose.

Verifica l'accesso (accedi, recupera il nome utente, ottieni la "data dell'ultimo accesso" o qualcosa di familiare ecc.)
Verifica il recupero del database (cerca un dato tag " schnitzelmitkartoffelsalat " -, cerca gli ultimi tag)
Prova i servizi web (connettiti, ottieni il numero di versione, recupera dati semplici, recupera dati dettagliati, modifica dati)

Ogni punto di prova ha punti secondari, come indicato tra parentesi. Abbiamo diviso questi gerarchici. Prendi l'ultimo esempio:

3. Connect to a web service
    ...
3.1. Get the version number
    ...
3.2. Data:
    3.2.1. Get the version number
    3.2.2. Retrieve simple data
    3.2.3. Retrieve detailed data
    3.2.4. Change data

Se un punto fallisce (durante lo sviluppo) invia un messaggio di errore esatto . Cioè 3.2.2. fallito. Quindi l'unità di test non eseguirà i test per 3.2.3. e 3.2.4. . In questo modo viene visualizzato un messaggio di errore (esatto): "3.2.2 non riuscito". Lasciare quindi il programmatore per risolvere quel problema (prima) e non gestire 3.2.3. e 3.2.4. perché questo non funzionerebbe.

Ciò ha aiutato molto a chiarire il problema e chiarire cosa bisogna fare all'inizio.

Tendo a lasciarli dentro, con l'attributo Ignore (utilizza NUnit ) - il test è menzionato nell'output dell'esecuzione del test , quindi è visibile, si spera che significhi che non lo dimenticheremo. Prendi in considerazione l'aggiunta dell'ID emissione / ticket in " ignora " Messaggio. In questo modo verrà risolto quando il problema di fondo è considerato maturo - sarebbe bello risolvere subito i test falliti, ma a volte piccoli bug devono aspettare fino al momento giusto.

Ho considerato l'attributo Explicit , che ha il vantaggio di poter essere eseguito senza una ricompilazione, ma non richiede un "motivo" e nella versione di NUnit che eseguiamo, il test non viene visualizzato nell'output come non eseguito.

Penso che tu abbia bisogno di un osservatore TODO che produca il "TODO" commenti dalla base di codice. TODO è i metadati del test. È una riga davanti al messaggio di errore noto e molto facile da correlare.

I TODO sono buoni. Usali. Gestirli attivamente inserendoli nel backlog su base regolare.

# 5 su Joey's " 12 passaggi per migliorare il codice " risolve i bug prima di scrivere un nuovo codice:

Quando hai un bug nel tuo codice che vedi la prima volta che provi a eseguirlo, sarai in grado di risolverlo in pochissimo tempo, perché tutto il codice è ancora fresco nella tua mente.

Se trovi un bug in un codice che hai scritto qualche giorno fa, ti ci vorrà un po 'per cercarlo, ma quando rileggi il codice che hai scritto, ti ricorderai tutto e sarai in grado per correggere l'errore in un ragionevole lasso di tempo.

Ma se trovi un bug nel codice che hai scritto qualche mese fa, probabilmente avrai dimenticato molte cose su quel codice, ed è molto più difficile da risolvere. A quel punto potresti aver corretto il codice di qualcun altro, e potrebbero essere ad Aruba in vacanza, nel qual caso, correggere l'errore è come una scienza: devi essere lento, metodico e meticoloso, e non puoi essere sicuro di come ci vorrà molto per scoprire la cura.

E se trovi un bug nel codice che è già stato spedito, dovrai sostenere spese incredibili per risolverlo.

Ma se vuoi davvero ignorare i test falliti, usa l'attributo [Ignora] o il suo equivalente in qualunque framework di test usi. Nell'output HTML di MbUnit, i test ignorati sono visualizzati in giallo, rispetto al rosso dei test falliti. Questo ti consente di notare facilmente un nuovo test fallito, ma non perderai la traccia dei test noti falliti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow