Devo fazer testes de unidade para defeitos conhecidos?

Se meu código contiver um defeito conhecido que deve ser corrigido, mas ainda não está, e não será corrigido para a versão atual e pode não ser corrigido em um futuro previsível, deve haver um teste de unidade com falha para esse bug em a suíte de teste? Se eu adicionar o teste de unidade, ele (obviamente) falhará, e me acostumar a ter testes reprovados parece uma má ideia. Por outro lado, se for um defeito conhecido e houver um caso de falha conhecido, parece estranho mantê-lo fora do conjunto de testes, pois ele deve ser corrigido em algum momento e o teste já está disponível.

A resposta é sim, você deve escrevê-los e executá-los.

Sua estrutura de teste precisa de uma categoria de "testes com falha conhecidos" e você deve marcar esses testes como se enquadram nessa categoria. Como você faz isso depende da estrutura.

Curiosamente, um teste que falha repentinamente pode ser tão interessante quanto um teste que falha inesperadamente.

Eu acho que você deve ter um teste de unidade com o comportamento atual e, nos comentários, adicionar o teste e o comportamento certos. Exemplo:

@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));
}

Dessa forma, quando a correção estiver disponível, a construção falhará, notando o teste que falhou. Ao analisar o teste, você saberá que mudou o comportamento e o teste deve ser atualizado.

EDIT: Como o Capitão Man disse, em grandes projetos, isso não será corrigido tão cedo, mas para o bem da documentação, a resposta original é melhor do que nada.

Uma maneira melhor de fazer isso é duplicar o teste atual, fazendo com que o clone afirme a coisa certa e @Ignorecom uma mensagem, por exemplo

@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));
}

Isso vem com a convenção da sua equipe para reduzir o número de @Ignoretestes d. Da mesma maneira que você faria com a introdução ou alteração do teste para refletir o bug, exceto que você não falha na compilação se isso for crítico para sua equipe, como a OP disse que o bugfix não será incluído na versão atual .

Dependendo da ferramenta de teste, você pode usar uma função omitou pend.

Exemplo em 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

O omitcomando pula um teste, o omit_ifcombina com um teste - no meu exemplo eu testo o número da versão e executo o teste apenas para versões em que espero que o erro seja resolvido.

A saída do meu exemplo é:

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

Então, minha resposta: Sim, implemente o teste. Mas não confunda um testador com erros, pois sabe que ele falhará.

Se o bug estiver fresco em sua mente e você tiver tempo para escrever o teste de unidade agora, eu o escreveria agora e o sinalizaria como uma falha conhecida, para que não falhe na compilação. Seu rastreador de erros deve ser atualizado para refletir que há um teste de unidade que está atualmente falhando para esse erro, para que a pessoa designada para corrigi-lo não o escreva novamente. Isso supõe que o código de buggy não precise de muita refatoração e que a API mude significativamente - se esse for o caso, é melhor você não escrever o teste de unidade até ter uma idéia melhor de como o teste deve ser escrito. .

A resposta é NÃO IMHO. Você não deve adicionar um teste de unidade para o bug até começar a trabalhar na correção do bug e depois escrever os testes que comprovam o bug e quando esses testes falharem de acordo com o relatório de erros ( s) você corrigirá o código real para fazer o (s) teste (s) passar (s) e o bug será resolvido e será coberto depois disso.

No meu mundo, teríamos um caso de teste manual em que os QEs falhariam até que o bug fosse corrigido. E nós, como desenvolvedores, estaríamos cientes disso através do TC com falha manual e do rastreador de erros.

O motivo para não adicionar UTs com falha é simples. As UTs são para feedback direto e validação do que eu, como desenvolvedor, estou trabalhando atualmente. E as UTs são usadas no sistema de CI para garantir que eu não quebrei algo acidentalmente em alguma outra área de código desse módulo. Ter UTs falhando intencionalmente por um bug conhecido IMHO seria contraproducente e simplesmente errado.

Suponho que a resposta seja realmente, depende. Seja pragmático sobre isso. O que escrever agora você ganha? Talvez esteja fresco em sua mente?

Ao corrigir o erro, faz todo o sentido provar que ele existe escrevendo um teste de unidade que expõe o erro. Você então corrige o bug e o teste de unidade deve passar.

Você tem tempo para escrever o teste de unidade com falha agora? Existem recursos ou bugs mais urgentes que precisam ser gravados / corrigidos.

Supondo que você tenha um software competente de rastreamento de bugs com o bug registrado, não há realmente nenhuma necessidade de escrever o teste de unidade com falha no momento .

Pode-se argumentar que você pode apresentar alguma confusão se apresentar um teste de unidade com falha antes de uma versão que está acontecendo sem a correção do bug.

Geralmente me sinto desconfortável por ter conhecido falhas em suítes de testes, porque é muito fácil a lista crescer com o tempo ou falhas não relacionadas nos mesmos testes serem descartadas como "esperadas". O mesmo vale para falhas intermitentes - pode haver algo de mal oculto no código. Eu votaria para escrever o teste para o código como está agora, e como deveria ser assim que for corrigido, mas comentado ou desativado de alguma forma.