Devo avere test unitari per difetti noti?

Se il mio codice contiene un difetto noto che dovrebbe essere corretto, ma non lo è ancora, e non sarà risolto per la versione corrente e potrebbe non essere risolto in un futuro prevedibile, dovrebbe esserci un test unitario fallito per quel bug in la 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 si riscontra un caso di fallimento noto, sembra strano tenerlo fuori dalla suite di test, come dovrebbe essere riparato ad un certo punto e il test è già disponibile.

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

Il tuo framework di test ha bisogno di una categoria di "test falliti noti" e dovresti contrassegnarli come rientranti in quella categoria. Come lo fai dipende dal framework.

Curiosamente, un test fallito che passa all'improvviso può essere altrettanto interessante di un test che passa inaspettatamente.

Penso che dovresti avere un test unitario con il comportamento attuale e nei commenti, aggiungere il test giusto e il comportamento giusto. 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 il test deve essere aggiornato.

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

Un modo migliore per farlo è duplicare il test corrente, facendo affermare al clone la cosa giusta e @Ignorecon 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 viene fornito con la convenzione del tuo team per ridurre il numero di @Ignored test. Allo stesso modo in cui si farebbe con l'introduzione o la modifica del test per riflettere il bug, tranne per il fatto che non si fallisce la compilazione se questo è fondamentale per il proprio team, come OP ha detto che il bugfix non verrà incluso nella versione corrente .

A seconda dello strumento di test è possibile utilizzare una funzione omito pend.

Esempio in rubino:

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 omitcomando salta un test, lo omit_ifcombina con un test - nel mio esempio collaudo il numero di versione ed eseguo il test solo per le versioni in cui prevedo che l'errore sia stato 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à.

Se il bug è fresco nella tua mente e hai il tempo di scrivere il test unitario ora, allora lo scriverei ora e lo contrassegnerei come un fallimento noto in modo che non fallisca la build stessa. Il tuo bug tracker dovrebbe essere aggiornato per riflettere che esiste un test unitario che al momento non riesce per questo bug in modo che la persona assegnata alla fine lo risolva, non lo riscrive di nuovo. Ciò suppone che il codice errato non abbia bisogno di molti refactoring e che l'API cambi in modo significativo - in tal caso, potrebbe essere meglio non scrivere il test unitario fino a quando non si ha una migliore idea di come deve essere scritto il test .

La risposta è NO IMHO. Non è necessario aggiungere un test unitario per il bug fino a quando non si inizia a lavorare sulla correzione per il bug e quindi si scriveranno i test che provano il bug e quando i test falliscono in conformità con la segnalazione dei bug ( s) andrai a correggere il codice effettivo per far passare i test e il bug verrà risolto e verrà coperto dopo.

Nel mio mondo avremmo un caso di test manuale in cui i QE falliscono fino a quando il bug non viene corretto. E noi come sviluppatori ne saremmo consapevoli tramite il manuale TC in errore e tramite il tracker dei bug.

La ragione per non aggiungere UT in errore è semplice. Le UT sono per feedback diretto e validazione di ciò che io come sviluppatore sto attualmente lavorando. E gli UT vengono utilizzati nel sistema CI per assicurarsi che non abbia infranto involontariamente qualcosa in un'altra area di codice per quel modulo. Avere gli UT che falliscono intenzionalmente per un bug noto IMHO sarebbe controproducente e semplicemente sbagliato.

Suppongo che la risposta sia davvero, dipende. Sii pragmatico al riguardo. Cosa ti guadagna ora a scriverlo? Forse è fresco nella tua mente?

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

Hai tempo per scrivere il test unit fallito proprio ora? Esistono funzioni o bug più urgenti che devono essere scritti / corretti.

Supponendo che tu abbia un software di tracciamento dei bug competente con il bug registrato, non è davvero necessario scrivere il test dell'unità fallito in questo momento .

Probabilmente potresti creare un po 'di confusione se introduci un test unitario fallito prima di un rilascio che sta avvenendo senza la correzione di bug.

Di solito mi sento a disagio per aver riscontrato errori 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 "previsti". Lo stesso vale per i guasti intermittenti: potrebbe esserci qualcosa di malvagio in agguato nel codice. Vorrei votare per aver scritto il test per il codice così com'è ora e come dovrebbe essere una volta che è stato risolto ma commentato o disabilitato in qualche modo.