Devo avere dei test unitari per i difetti noti?

35

Se il mio codice contiene un difetto noto che dovrebbe essere riparato, ma non lo è ancora, e non sarà corretto per la versione corrente, e potrebbe non essere corretto nel prossimo futuro, dovrebbe esserci un test dell'unità fallito per quel bug nella suite di test? Se aggiungo il test unitario, fallirà (ovviamente) e abituarsi ad avere dei test falliti sembra una cattiva idea. D'altra parte, se si tratta di un difetto noto, e vi è un caso di fallimento noto, sembra strano tenerlo fuori dalla suite di test, poiché a un certo punto dovrebbe essere corretto e il test è già disponibile.

    
posta Martijn 31.01.2014 - 13:38
fonte

7 risposte

50

La risposta è sì, dovresti scriverli e dovresti eseguirli.

Il tuo framework di test ha bisogno di una categoria di "test di failing noti" e dovresti contrassegnare questi test come appartenenti a quella categoria. Il modo in cui lo fai dipende dal framework.

Stranamente, un test fallito che passa improvvisamente può essere interessante quanto un test di passaggio che non riesce in modo inaspettato.

    
risposta data 31.01.2014 - 13:47
fonte
5

Penso che dovresti avere un test unitario con il comportamento corrente e nei commenti, aggiungere il giusto test e il giusto comportamento. Esempio:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

In questo modo, quando la correzione è disponibile, la compilazione fallirà, notando il test fallito. Quando guarderai il test, saprai che hai cambiato il comportamento e che il test deve essere aggiornato.

EDIT: Come ha detto il Capitano Man, nei progetti di grandi dimensioni, questo non verrà risolto in qualsiasi momento, ma per la documentazione, la risposta originale è meglio di niente.

Un modo migliore per farlo è duplicare il test corrente, fare in modo che il clone asserisca la cosa giusta e @Ignore con un messaggio, ad es.

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Questo include la convenzione del tuo team per ridurre il numero di test di @Ignore d. Nello stesso modo in cui si farebbe introducendo o modificando il test per riflettere il bug, eccetto che non si fallisce la build se questo è fondamentale per il proprio team, come OP ha detto che il bugfix non sarà incluso nella versione corrente .

    
risposta data 31.01.2014 - 13:50
fonte
3

A seconda dello strumento di test puoi utilizzare una funzione omit o pend .

Esempio in ruby:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

Il comando omit salta un test, omit_if lo combina con un test - nel mio esempio, eseguo il test del numero di versione ed eseguo il test solo per le versioni in cui prevedo che l'errore sia risolto.

L'output del mio esempio è:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in 'test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in 'test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

Quindi la mia risposta: Sì, implementa il test. Ma non confondere un tester con errori, dove sai che fallirà.

    
risposta data 31.01.2014 - 20:17
fonte
2

Se il bug è nuovo nella tua mente e hai il tempo di scrivere il test unitario ora, allora lo scrivo ora e lo contrassegno come un errore noto, quindi non fallisce la build stessa. Il tuo bug tracker dovrebbe essere aggiornato per riflettere sul fatto che esiste un test unitario attualmente non funzionante per questo bug, in modo che la persona assegnata alla sua correzione non la scriva di nuovo. Ciò suppone che il codice buggy non abbia bisogno di molto refactoring e che l'API cambi in modo significativo - se questo è il caso, allora potrebbe essere meglio non scrivere il test unitario finché non hai un'idea migliore di come dovrebbe essere scritto il test .

    
risposta data 31.01.2014 - 13:47
fonte
1

La risposta è NESSUNA IMHO. Non dovresti aggiungere un test unitario per il bug fino a quando non inizi a lavorare sulla correzione per il bug e poi scriverai i test che dimostrano il bug e quando quel test (i) falliscono in accordo con il bug report ( s) andrai a correggere il codice effettivo per fare passare il / i test / i e il bug sarà risolto e dopo sarà coperto.

Nel mio mondo avremmo un caso di test manuale che i QE hanno fallito fino a quando il bug non viene corretto. E noi come gli sviluppatori ne saremmo a conoscenza attraverso il manuale di failing TC e tramite il bug tracker.

Il motivo per non aggiungere errori UT è semplice. Gli UT sono per il feedback diretto e la validazione di ciò che io come sviluppatore stiamo attualmente lavorando. E gli UT sono usati nel sistema di CI per essere certi di non aver rotto qualcosa involontariamente in qualche altra area di codice per quel modulo. Avendo fallito intenzionalmente l'UT per un bug noto, IMHO sarebbe controproducente e semplicemente sbagliato.

    
risposta data 31.01.2014 - 15:36
fonte
0

Suppongo che la risposta sia davvero, dipende. Sii pragmatico al riguardo. Cosa ti fa guadagnare ora la scrittura? Forse è fresco nella tua mente?

Quando si corregge il bug, ha perfettamente senso provare che esiste scrivendo un test unitario che espone il bug. Quindi correggi il bug e il test dell'unità dovrebbe passare.

Hai il tempo di scrivere il test dell'unità fallito proprio ora? Ci sono altre funzionalità o bug che devono essere scritti / risolti.

Supponendo che tu abbia un software di tracciamento dei bug competente con il bug registrato, non c'è davvero bisogno di scrivere il test dell'unità guasto adesso .

Probabilmente potresti introdurre qualche confusione se introduci un test dell'unità guasto prima di un rilascio che si sta verificando senza la correzione del bug.

    
risposta data 31.01.2014 - 14:31
fonte
0

Di solito mi sento a disagio nell'avere dei fallimenti noti nelle suite di test, perché è troppo facile che l'elenco cresca nel tempo, o che gli errori non correlati negli stessi test vengano liquidati come "attesi". Lo stesso vale per i guasti intermittenti: potrebbe esserci qualcosa di malvagio in agguato nel codice. Voterò per scrivere il test per il codice come è adesso, e come dovrebbe essere una volta che è stato riparato ma commentato o disabilitato in qualche modo.

    
risposta data 31.01.2014 - 14:36
fonte

Leggi altre domande sui tag